EricJ

I was going to suggest 3D printing one. If any of your local high schools with a robotics or similar programs has a 3D printer (which they often do), they'll probably be happy to make you one for a little sponsorship money or mentoring time. I judge at FIRST robotics events and the teams print structural parts and all kinds of stuff for their bots. Most of them are quite good at it, and a knob would be a pretty simple project, I'd think, if they had one to make a pattern from. Last week I was at an event in Flagstaff and one of the teams had printed a model of the tournament field and put it on a white board to sort out strategy with alliance teams.

Some of the newer stuff is less sensitive to the impedance mismatch created by a missing load (antenna), so I'm not too surprised. Not sure what a swing test is, though. That said, the 406 units (I have an ACK-04, too) still have self-test modes, . My ACK-04 manual says that it is supposed to be self-tested every three months, and there's no mention of removing the antenna. I think the self-test 406 signal is distinguishable from the activated signal, so I don't think that's a problem. You can still listen on 121.5 for the one-second test signal. I did get a call from the Air Force when the avionics guys set mine off in their shop and didn't know it. Was nice to know the system works.

You should turn the ELT off when fiddling with the antenna, and I'd even disconnect the antenna cable at the ELT before working on the antenna. This will help protect the output of the power amplifier from any transients or static discharge while you're handling the conductors around the antenna. If the ELT transmitter comes on (inadvertently or for whatever reason) while the antenna is missing or disconnected it can damage the transmit power amplifier. Likewise handing the output conductor via static discharge (from a person or a tool to it). Once you're all done with an antenna replacement, execute the self test and make sure it can be heard strongly on a 121.5 receiver. That'll let you know that the amplifier survived the entire process.

Yeah, usually the system requirements (which drive the requirements for everything else) have this sort of analysis thoroughly gone through. A faulty sensor isn't a software problem, but mitigation should come from the system design and requirements. Usually that stuff is gone over sixteen ways from Sunday. I'll be interested to see what shakes out.

While I don't disagree, Howard Hughes was wealthy because his Dad sorted out how to make money renting drill bits to oil field deployments. Both parties benefited, so it was a successful business model. It's been going on a long time.

If it's a code bug I'll be very interested to see how verification missed it.

I worked for a while in the early 90s on the comm module in the AIMS cabinet in the Honeywell avionics in the B777. I designed the circuit hardware for much of the comm box, including one of the first ACARS modems that got any significant broad use, and I also did a lot of HDL and some software for the modem. It was a good experience for me as we got a LOT of training in formal verification methods for hardware and software, because the certification process for air transport is thorough. Basically, at least in those days, every line of code is formally tested, every condition of every branch is tested, every path of every conditional is tested, every case of a case statement, every state of every input condition is tested, etc., etc. The test plan has to show how each of these things gets accomplished. I found it excellent training as it's actually not that hard or egregious to do, and it's extremely effective at finding bugs. It also makes your write more efficient code. I've used those methods throughout my career very effectively and was always glad for the experience. So when I hear of an expensive bug found because of an untested condition or code that didn't get exercised or a table entry that never got sampled (like the Pentium bug, if you remember that), I always think of this stuff and that it was a preventable error. There's a reason very few software bugs turn up in airliners compared to almost anywhere else. The testing and verification methods are very good. They're expensive and take effort, but they're good.

Also, it looks like there's a conformal coating on the board, which will have to be removed around the component before replacing. But, generally, yeah, just stick a reasonably spec'ed diode on there and see if it works. FWIW, diodes don't fail very often. Replacing the diode may not fix the problem, either because the diode isn't actually failed or because whatever caused it to fail is still bad.

Those little ones can be difficult to rework, e.g., replace, without proper equipment and experience. Even experienced techs generally don't like working with that stuff. But, yeah, an assembly pic might still help, plus anything you might know about the circuit.

A pic might help.

Regardless, it's probably the Mooney with the most cabin space.

Is that the sort of thing that's classified as MRSA? Bad stuff if so.

A few years ago I bought some of those and gave most away as gifts. I think they're marginally useful, better than nothing, but not nearly as good as having a decent monitor with a numerical display.

When I was reading it I was thinking it was starting to look like an intentional act.

I have traffic on my IFD540 display which comes from an in-panel FreeFlight Ranger, and on the two tablets I fly with that get traffic from my Stratux. There are often differences between them, and sometimes there'll be a target on one that isn't on the other, and it goes both ways. There are subtle differences of why that can happen, and it does often enough to not be unusual. It's one of the reasons I fly with that much redundancy, because around here you can use all the help you can get when it comes to traffic awareness.