What's the deal with the Navy trainers?

This thread went full retard quite early. I don't know where the engineer umbrage is coming from personally. As @Hacker pointed out, these things are not all created equal. Implementation of OBOGS systems vary with airframes, and failure modes pop up from time to time.

I flew the T-6A for 1000 hours in the USAF side. OBOGS jet. The Navy got the T-6B and much later than the AF had been flying the As. So far it doesn't look like they're having issues compared to the 45s. Likewise we don't know to what degree the airframes are being maintained in the NAVY compared to the USAF. To be clear, both use bottom of the barrel, local economy jobs program civil service or contract "talent" to staff the maintenance shops at the grunt level.

I was never fond of the magic of OBOGS in the T-6, but thankfully I never experienced a canister failure dumping that dust all over my throat. Of course I won't know until later in life if I indeed breathed that crap in imperceptible quantities to my body's allergic trigger point, and whether it will have shortened my life span. "Thank you for my service" am I right?

I'm back now in the T-38 where we breath that craptastic ol school LOX bottle that leaks all the time and leaves you stranded off station. But since I'm old school like that, at least I know the failure modes of that thing. The devil I know is much preferred to the devil I don't know.

In the case of the Raptor, that had to do with the fact the OBOGS could not concentrate enough volume to make decent oxygen at the bozosphere level. Many 22 drivers refused to fly the thing for a while. So this isn't just a slight to the NAVY.

I commend the instructor cadre for taking a stand though; we are responsible for these kids live's when they don't have enough experience to know better.
Straight from the horses mouth here folks. Thanks @hindsight2020 for not crapping all over the place, and thank you for your service! :thumbsup:
 
I've been an engineer (OK software) and have endured many product meetings where things got shipped that shouldn't. But I've also had plenty of things that happened in the field that I never anticipated. If you haven't, I'd guess you haven't built that many systems. Or you're God..

Software doesn't count. Software engineers want to rewrite even their own code the day it releases. Let alone someone else's when they see it.
 
@nauga, and @35aoa, is this the same problem the Hornet had?
 
It would seem that if it is contaminant in the system, the way to figure out what is would be to hook up a personal air sampling pump and a sample container (they can be pretty small) to the mask in a bunch of planes and go for a ride. Might have to do this with several planes for a few weeks/months for the issue to crop up. Run the air samples for a variety of stuff that might be the culprit. Not terribly cheap to do, but a whole lot cheaper than losing a bird or pilot to a contaminated system. Obviously just do the test on birds that have been suspected of an issue recently. Ground testing might work, but may only be a problem that shows up when airborne.

Since I apparently need to have qualifications to have an opinion - I'm a trained safety supervisor to work in potentially hazardous atmospheres, and occupational health and safety air sampling is something we do fairly regularly.
 
Might have to do this with several planes for a few weeks/months for the issue to crop up. Run the air samples for a variety of stuff that might be the culprit.
Reports say that's been done, with inconclusive results. There are conflicting reports on how extensive that testing has been.

Nauga,
huffing
 
The same "inconclusive results" that caused the Raptor guys to mutiny back in '12...
 
Navy beans.....leads to flatulence.....equals bad day flying...?
Ya know, I've honestly never seen 'navy beans' in any chow line on any ship I ever served on.

Just an odd observation.....now back to your regularly scheduled engineer bashing....
 
Ya know, I've honestly never seen 'navy beans' in any chow line on any ship I ever served on.

Just an odd observation.....now back to your regularly scheduled engineer bashing....

Must have been a WWII thing then. My dad was Navy from 43 to 47. And he still liked navy beans. I bet if I looked hard enough I would probably find a few cans my dad put in storage more than 20 years ago....:lol::lol::vomit:

And sorry to interrupt the main conversation. Back to observing.....:popcorn:
 
My very first computer class lecture started of with something like the following...
"When Henry Ford designed the Model T he eyeball engineered it, as a result some parts failed relatively quickly and others are still out in the back pasture perfectly serviceable. Now days cars are designed using numerical analysis thanks to computers most parts are designed with a specific life span in mind, as a result modern car tend to start falling apart all at once."

Brian

Ever read about the deacon's one-hoss shay, that lasted 100 years to the day?
 
@nauga, and @35aoa, is this the same problem the Hornet had?

Late to the food fight, but I don't know whether the problems mentioned here are similar, or of a different nature. I've long since forgotten everything about the T-45…….I could barely keep the 3 NATOPS quals I had in my last job straight in my head :)
 
I've long since forgotten everything about the T-45…
*shudder* I wish I could o_O
Speaking of which, first flight was 29 years ago on 16 April 1988. You have no idea how old it makes me feel to type that.

Nauga,
strange in a stranger land
 
My very first computer class lecture started of with something like the following...
"When Henry Ford designed the Model T he eyeball engineered it, as a result some parts failed relatively quickly and others are still out in the back pasture perfectly serviceable. Now days cars are designed using numerical analysis thanks to computers most parts are designed with a specific life span in mind, as a result modern car tend to start falling apart all at once."

Brian
That is brilliant. Thanks.
 
*shudder* I wish I could o_O
Speaking of which, first flight was 29 years ago on 16 April 1988. You have no idea how old it makes me feel to type that.

Nauga,
strange in a stranger land

Old man :) Speaking of old things, I still wish I would have gotten a chance to fly the T-2. I missed the pilot window by a good number of years (I think the last guys were on this years aviation command screen board), but they were still in VT-86 when I went through API……cool to watch them flying around, though there weren't a whole lot of open backseats around there, if you know what I mean :)
 
Old man :) Speaking of old things, I still wish I would have gotten a chance to fly the T-2.
Being old does have its advantages. I've got a few hours in the back seat and loved every one. Spins (upright and inverted), endos, tailslides (tip dumps - ON), and a BSEG.
buckeye_small-jpg.45051


Nauga,
behind the mask
 
Being old does have its advantages. I've got a few hours in the back seat and loved every one. Spins (upright and inverted), endos, tailslides (tip dumps - ON), and a BSEG.
buckeye_small-jpg.45051


Nauga,
behind the mask
Now you're really showing your age.....when did they retire those helmets with the visor cover?
 
Now you're really showing your age.....when did they retire those helmets with the visor cover?
Early '90's. I have some pics with HGU55's too, but I'd have to dust off my old scanner :p

Nauga,
who also rode the Whale :cool:
 
Program managers getting crapped on left and right but I am not getting panties in a wad. I have worked with engineers like PAFlyer. Their reputation always proceeds them and they rarely are sought after to move programs.
 
Come on folks. Engineers do not design things to break. That is pure nonsense! They just design things to be hard to replace when they do fail. I have scarred knuckles to prove it!

Sure we do. We design things to break exactly (or statistically) when we want them to (as defined by our customers, sales, marketing, and management). To do otherwise would result in something that was unrealistically expensive (and/or heavy in aerospace) which would never sell.
 
Program managers getting crapped on left and right...
The funny thing is that engineers aren't even being crapped on. @Hacker made the inexcusable error in pointing out that somehow an engineer might be human and miss something, which we now know by @paflyer's post that that is an impossibility. If there is an error somewhere, it must most certainly be the pilots', program managers', executives', etc., fault. And if you don't have a MSEE, you are not qualified to disagree. So, salute sharply and carry on...
 
The funny thing is that engineers aren't even being crapped on. @Hacker made the inexcusable error in pointing out that somehow an engineer might be human and miss something, which we now know by @paflyer's post that that is an impossibility. If there is an error somewhere, it must most certainly be the pilots', program managers', executives', etc., fault. And if you don't have a MSEE, you are not qualified to disagree. So, salute sharply and carry on...

But it is never the mechanic's fault. We just have to deal with the all of the many mistakes made by all of the people you listed.

:D
 
If there is an error somewhere, it must most certainly be the pilots' [...] fault.
If we could just get you guys to stop breathing we wouldn't be having these problems. In that case I guess the problem is also the solution...o_O

Nauga,
hypoxically yours
 
Well, I understand that a few years ago the Navy gave up on the engineers solving the problem and brought in a group of scientists instead. After 2 years of research and $45M, the scientists arrived at a solution and released their report.

It began, "First, assume an anaerobic pilot..."
 
There was a public scandal a few years involving F-22 pilots who refused to fly because of oxygen problems and went public about it.

After denying that there was a problem the USAF wound up modifying the fleet.
 
I've literally spent a half a lifetime cleaning up messes caused by engineers. I like it. It pays real well. Not as good as some of the top engineers but better than the mediocre ones.

Thing is, I don't mind. Some of them love that I help them. Some wish I didn't exist but tolerate me. The few that don't like that I'm a necessary part of the team, I just challenge to make their product so good, they never have to see me again. They can even split my salary if they pull it off at most places.

Airplanes are a hell of a lot harder than software. Software does exactly what it was told to do.

Materials subjected to all the fun of a fighter aircraft, are bound to do some unwanted things from time to time. I wouldn't want to troubleshoot that stuff. It's pretty easy to find the module or section of code that is doing the wrong thing because it was coded that way.
 
I've literally spent a half a lifetime cleaning up messes caused by engineers. I like it. It pays real well. Not as good as some of the top engineers but better than the mediocre ones.

Thing is, I don't mind. Some of them love that I help them. Some wish I didn't exist but tolerate me. The few that don't like that I'm a necessary part of the team, I just challenge to make their product so good, they never have to see me again. They can even split my salary if they pull it off at most places.

Airplanes are a hell of a lot harder than software. Software does exactly what it was told to do.

Materials subjected to all the fun of a fighter aircraft, are bound to do some unwanted things from time to time. I wouldn't want to troubleshoot that stuff. It's pretty easy to find the module or section of code that is doing the wrong thing because it was coded that way.

I love having people like you involved. It gets me more insight into things I may never have seen, which lets me do a better job.

But if you think software only does what it's told, you haven't written software for hardware in development. Or found any compiler bugs. Or found the race condition in a processor.

Almost all of the time it does what it's told.
 
I love having people like you involved. It gets me more insight into things I may never have seen, which lets me do a better job.

But if you think software only does what it's told, you haven't written software for hardware in development. Or found any compiler bugs. Or found the race condition in a processor.

Almost all of the time it does what it's told.

Sure I have. I have found compiler bugs. Haven't run into a production silicon bug in a CPU but definitely in a DSP.

Those examples are still doing exactly what they were told to do. The person wasn't in the building but someone still screwed up.

Even calling them bugs is a bit of marketing wank. It was only true for Grace Hopper. The "bug list" really should be titled "mistake list".

Imagine the subtle shift of attitude toward such things if they didn't have a cute name based on a moth getting caught in a relay. A mistake list might lead to someone saying, "Why do y'all make so many mistakes and how can we lower the number of mistakes?"

Instead of what often happens... "Let's celebrate the squashing of our ten thousandth bug today!" (Yep, we made that many mistakes. Let's have cake!)
 
Sure I have. I have found compiler bugs. Haven't run into a production silicon bug in a CPU but definitely in a DSP.

Those examples are still doing exactly what they were told to do. The person wasn't in the building but someone still screwed up.

Even calling them bugs is a bit of marketing wank. It was only true for Grace Hopper. The "bug list" really should be titled "mistake list".

Imagine the subtle shift of attitude toward such things if they didn't have a cute name based on a moth getting caught in a relay. A mistake list might lead to someone saying, "Why do y'all make so many mistakes and how can we lower the number of mistakes?"

Instead of what often happens... "Let's celebrate the squashing of our ten thousandth bug today!" (Yep, we made that many mistakes. Let's have cake!)

I like the Dilbert where they've decided to pay a bounty on bugs fixed and Wally says "I'm gonna code myself a new minivan!"

Sometimes they are mistakes. Sometimes there are interactions that probably couldn't be reasonably foreseen.

And, of course, there are those times when it's cheaper to fix the things that actually happen than to spend the time to analyze all possible failures and account for them.

We're building the most complex systems (out of other systems that we're not necessarily designed for the purpose) that mankind has ever built. I'd argue that anybody who thinks they can be built without ever encountering a case they didn't foresee suffers from hubris. I've built some damn good software (some of which is still chugging away buried where nobody's likely to ever notice it unless it breaks (which it hasn't; that's why it's still chugging away). I've also built some trash that should never have been given to anybody. And I've also been surprised. It's not possible to know everything about every problem domain you work in.

If you think that's because I'm some sort of substandard engineer (especially because I build software), well so be it. But I still assert that if you've never been surprised by a fielded system then you haven't fielded very many.
 
I am interested in the actual thread: Unless there is firmware running in the 02 system and that FW is suspect, I think going off on coding is irrelevant. So it seems neither scientists or engineers have found the problem? Also seems the Navy (05 and up) has been willing to accept problems vs grind everything to a halt since they have pilots to train and missions to fly. So, way to go by the instructors for standing up to the brass! What are the latest working theories?
 
If you think that's because I'm some sort of substandard engineer (especially because I build software), well so be it. But I still assert that if you've never been surprised by a fielded system then you haven't fielded very many.

Not sub-standard. Quite standard. Software simply makes almost no effort to avoid the most common mistakes.

Everyone's been surprised by a fielded system or my job wouldn't exist. LOL. Everyone. So many people put up with faulty software that they actually believe it's normal.

If the walls of their houses fell down regularly or overpasses dropped with regularity, they'd not be pleased with the engineers. Not at all.

But they've been convinced by good marketing that problems that should have never been solved by a computer, needed one, then when the problem was actually made more difficult by the cheaply designed computer system, they were told that was normal and "we build the most complex things in the world!" Haha. Okay, so stop building complex things.

Anyway... I wonder what the "bug list" looks like on a continuous basis on aircraft designed to push the limits of physics to kill people. Bet it's an interesting list.
 
Anyway... I wonder what the "bug list" looks like on a continuous basis on aircraft designed to push the limits of physics to kill people. Bet it's an interesting list.
I'll bet it's not as interesting as you think. The time scale and testing scope of flight critical software are both far beyond what most non-aircraft software developers expect. Are you familiar with DO-178B or C? The 'walls fall down' failure you seem to think is the norm in software is extremely rare on fielded (flight critical) aircraft systems in my experience. It happens a lot in development and testing, where the bug lists are very real and closely monitored, but not so much after - and the less critical issues that crop up are usually deferred to the point where there are enough to warrant 'breaking the seal' on the validated code and fixing them due to the time and cost of testing and validating changes. Certainly the walls due fall down on occasion, and these changes get pushed through quickly, but with no less rigor than the initial development.

You might as well attribute *every* failure, hardware and software, to human error, because if it was designed, manufactured, and implemented "right" it wouldn't fail in an unexpected manner. And we can all live in peace and harmony with flowers and kittens and rainbows.

All that aside, the software discussion is a red herring. if the OBOGS issue under discussion is software-related, I'll eat my mask.

Nauga,
who doesn't care if it's soft or hard, as long as it does what it's supposed to
 
I'll bet it's not as interesting as you think.

...

You might as well attribute *every* failure, hardware and software, to human error, because if it was designed, manufactured, and implemented "right" it wouldn't fail in an unexpected manner. And we can all live in peace and harmony with flowers and kittens and rainbows.

...

All that aside, the software discussion is a red herring. if the OBOGS under discussion is software-related, I'll eat my mask.

...

Nauga,
who doesn't care if it's soft or hard, as long as it does what it's supposed to

Aww man. I was hoping for a nice Jira instance with entries like, "Only blew off half of the bad guy's face." :)

Humans are quite fallible, yes. We all build broken stuff. The question is always how broken.

Agree that it's unlikely to be software on this one, but also so far removed from it, I honestly don't care.

Ask ten people what any system is supposed to do, you'll get eleven answers! :)
 
Back
Top