Posts by user "MechEngr" [Posts: 8 Total up-votes: 3 Page: 1 of 1]¶

It has 2 bugs. 3 if one expects anything to show up on a terminal, at least it used to be the case that print statements were buffered until encountering \n or \r. The first two problems would be caught by most compilers. Fortunately all three will beat up a programmer pretty good in the first day or two so they stop doing that.

Over on reddit in /r/FPGA there are numerous complaints of tools producing incorrect outputs for FPGA and the observation that one cannot examine the state of an FPGA while it is operating; simulators are OK, but cannot reproduce slight timing variation related problems. At least with C one can, relatively easily, match 1:1 non-optimized compiled assembler output to the original input to see if the compiler is translating things correctly.

I expect FPGA if used are used for initial signal processing rather than logic. One can check that the processing is stable with signal generators and noise injection. The decision part is much more readable in C or Ada for people to decide if the logic is right and the test cases available can be used to verify that the compiler/linker is working OK, plus the aforementioned direct examination of the intermediate results, plus active debuggers to examine the state of the more conventional microprocessor.

Wood is a composite material. It might be a good match in the coefficient of thermal expansion to the carbon/epoxy composite and cheaper than making the fixture from carbon/epoxy composite, which would have itself required a support.

There are a lot of cameras in the world to record where pieces were found and in what condition and orientation. Concerns might be raised if the cleanup was with bulldozers and backhoes, but I would not expect that in this case. Additionally, a very important and relatively recent tool - the high-resolution camera-carrying multiblade drone can capture the entire debris field in a few hours of a single day. While I don't know if it would help, even thermal infrared camera-carrying drones are widely available and relatively cheap to better distinguish details that might be obscured in normal illumination.

Were this a crash into a forest, where trees would make over-view photography difficult, speed of collection might make a difference, but I think it is mainly open sky where additional photography can be done as layers of building debris are removed.

It could be done that way, but the secondary contact and wiring could fail and, unless a continuous power circuit was used to ensure that there wasn't a break, the digital recorder might not get coordinated information. This would also end up extended to all other switches making for a major increased in wiring and an increase in the number of channels for the FDR.

Small cameras capturing all the switches on each panel would be sufficient and make for a tiny increase in the amount of wiring while capturing not only the events with the switches, but also any actions of the crew, intentional or accidental.

Like, intending to push a button, but it was accidentally pushed an insufficient amount to engage, that sort of thing. For a few bucks more, a motion analysis module could decide what button or selection is being made, compare to the result to see if there is some problem, and/or generate an alert in response to operation outside of typical practice.

Since the effect of the state of the switches is usually immediate, the amount of recorded video need only be a few minutes. Example - it is unlikely that a switch that was in one position, moved, and then moved back, will have an effect that is only noticed 5 hours later. If the switch is put in the wrong position, then it will remain in the wrong position until it is moved, even if that wrong position causes an incident hours or days later, at which time it will still be on the video recording.

Yes - conflicting data issuing a warning when the system being controlled has no fault. That's a problem at considerable expense for a rare occurrence.

Literally covering all the bases with a video would not only show what the switch status was but also how it got there, if it has an immediate effect, which a second line would not do.

The proposal is to -also- stream to Starlink or the equivalent. No need for grounding for an optional accident investigation data stream that in no way affects safety of flight.

Carriers advertise all sorts of things. They tend to deliver on the transportation one with everything else optional to varying degrees.

One would need a detailed electrical schematic to determine what the function of the diode was. Absent the electrical schematic it's an idea that is not worth consideration.

There are two teeth on the switch body and two teeth on the plunger that is pulled up to unlatch the switch. There is not enough room for a tooth on the plunger to fit between the switch toggle and the mating tooth on the switch body. It would require the toggle axle pin to break to allow that, allowing the toggle to fall off and the plunger with it.

Clearly the design of the latch requires that it move from one position to another position with some applied forces. Absent some clarification of what the pilot(s) did or observed, their statement matches the way the switch is supposed to function.

" However, applying external force in an incorrect direction caused the switch to move easily from RUN to CUTOFF, due to the angular base plate allowing slip when pressed improperly with finger or thumb.\x94

The problematic part of the statement is that there is nothing that says what they think the incorrect direction is. But, if one wants it to move it must be pushed in a direction that is incorrect for it to remain locked in position. It is almost certain that if one pushes towards the opposite position from the current locked one and, at the same time uses the friction from that push, one can pull the plunger up and disengage the lock.

Is that what they meant by "incorrect direction"? Who, besides them, know what they meant?