737 manual text:

Manual Stabilizer Trim

If manual stabilizer trim is necessary, ensure both stabilizer trim cutout switches are in CUTOUT prior to extending the manual trim wheel handles. Excessive airloads on the stabilizer may require effort by both pilots to correct the mis-trim. In extreme cases it may be necessary to aerodynamically relieve the airloads to allow manual trimming. Accelerate or decelerate towards the in-trim speed while attempting to trim manually.

Going faster than the max safe airspeed, having the stabilizer trimmed fully down and the elevator fully opposed to it seems like it might be the extreme case they’re thinking of. The NYTimes quote suggests that it would be possible with both pilots working together, but this old manual suggests to me that it was likely not.

if the workaround procedure was once mentioned in the manuals and then disappeared, that ought to mean that Boeing had fixed the problem.

I think we’re talking laws of physics against a mechanical system, so I don’t suspect there’s been a fix: seems like instead this kind of manual flight was simply no longer necessary until Boeing added a new system that causes you to become severely mistrimmed and then have to disable the motor that can fix that.

]]>briefly talking this over with another engineer reminds me of the concept of “code coverage”. there are millions of lines of code in the control systems but there is no “easy” way of knowing what code is getting exercised in even “supposedly extensive” tests. my feeling is that code coverage awareness/ analysis could have averted some of this disaster. its extraordinary that many complex systems are deployed with sometimes far less than 100% code coverage in tests, and achieving 100% is probably unrealistic. but it has to be weighed. # of lines of code needs to be seen as having a “sweet spot” and this is a mostly alien concept wrt modern engineering. too little and the control system is not sophisticated. too much and you get lower code coverage and “potentially ugly surprises in PROD” so to speak.

code coverage is tricky to measure because you almost need another computer to monitor your algorithm. so tracking code coverage typically adds execution time overhead. but building this monitoring into the chips themselves with low execution overhead is a possibility that is probably not much explored.

another key relevant concept is “happy path vs sad path”. most testing focuses on “happy path”. then “sad path” scenarios can be extremely challenging to simulate. they are basically “edge cases”. its possible MCAS was never very thoroughly tested because its mostly a “sad path” mechanism to deal with an “edge case”. another concept in code is if-then complexity. amount of conditional logic ideally should be minimized because if you have ‘x’ branches then you have 2^x paths of code to test and that decreases code coverage possibility.

]]>On the other hand, if the workaround procedure was once mentioned in the manuals and then disappeared, that *ought* to mean that Boeing had fixed the problem.

Followup: Just this morning the *New York Times* reports:

]]>Once the power was cut, the pilots tried to regain control manually by turning a wheel next to their seat. The 737 is the last modern Boeing jet that uses a manual wheel as its backup system. But Boeing has long known that turning the wheel is difficult at high speeds, and may have required two pilots to work together.

There is an interesting theory that I don’t think you mention anywhere. The theory is that, on the Ethiopian

flight, after disabling the stabilizer trim motor while there is mistrim, the aerodynamic load on the jackscrew was too great for it be movable by the copilot using their crank. The pilot was perhaps using their strength to pull the yoke back, which meant both that he was unavailable to help crank, and that the aerodynamic load was increased by the elevator directing airflow in opposition to the stabilizer.

There is an old “yo-yo maneuver” that stopped being mentioned in Boeing manuals decades ago that describes having to relieve load on the stabilizer before manually trimming, in this case by releasing the elevator and pushing the nose down even further, which I’m sure would have been very unattractive given their high airspeed and low altitude if the pilots even understood the procedure, which is no longer part of simulator training.

This may explain why the trim motor appears to have been re-enabled towards the end of the Ethiopian flight: because purely manual trim was impossible.

Any thoughts on these ideas?

]]>A friend and I figured out why your running product/quotient algorithm behaves the way it does.

**Period of 4**

Your running product/quotient sequence will start as follows:

\[n, \frac{n}{(n-1)}, \frac{n(n-2)}{(n-1)}, \frac{n(n-3)}{(n-1)(n-2)}, \dots\]

After the first multiplication which is a corner case (\(q=1\)), you divide twice, then multiply twice, divide twice and so on. It takes two multiplications/divisions to change from being less than one to more than one and vice versa. Let \(n, n-1, \dots, n-(k-1)\) have already been multiplied/divided in \(q\), that is, we have used \(k\) terms.

If \(k \mod 4\) is 1 or 2, then skip \(\frac{n}{n-1}\) which is greater than one and club 4 terms at a time. Each of these will also be greater than 1. So in both these cases we will choose to divide next.

\[\frac{n}{n-1}\cdot\frac{(n-3)(n-4)}{(n-2)} \textrm{ and } \frac{n}{n-1}\cdot\frac{(n-3)(n-4)}{(n-2)(n-5)}\]

On the other hand, if \(k \mod 4\) is 0 or 3, then club 4 terms at a time without skipping \(\frac{n}{n-1}\). Each of these terms will less than 1 and we will choose to multiply next.

\[\frac{n(n-3)}{(n-1)(n-2)}\cdot\frac{(n-4)}{(n-5)(n-6)} \textrm{ and } \frac{n(n-3)}{(n-1)(n-2)}\cdot\frac{(n-4)(n-7)}{(n-5)(n-6)}\]

Formalizing this is easy using induction (done case by case using mod 4 arguments) and that will prove that the period is 4.

**Convergence value**

We did this for the case where \(n = 4k\) but the other cases should be similar (although messier). Writing out the value of \(q\) as a function of \(k\) we get the following:

\[\prod_{n=1}^{\infty} \frac{4n(4n-3)}{(4n-1)(4n-2)} = \sum_{n=1}^{\infty} \log \frac{4n(4n-3)}{(4n-1)(4n-2)}\]

Wolfram alpha tells us this converges to -0.222251 one of the values you noticed numerically. Here’s the link.

]]>Among the most common programming operators, the only ones that are not “easy” would be exponentiation (when not evaluated left-to-right), integer modulo (maybe interesting) and bitwise XOR (certainly interesting). There’s also the C comparison operators which also work as Boolean operators, but I can’t think of anything more to say about them.

]]>Kirkpatrick’s paper mentions Ising and Nicholas Metropolis but does not mention Glauber.

]]>They’re all related to one another by being in the set of relations. And of course each can have a set of other properties, like symmetry / anti-symmetry, one-to-one / many-to-one / one-to-many, containing vs. membership, transitive, associative, what-have-you.

You might think you still need a key for relations, but really anything that gets you in is not more than two steps away from the set of relations, providing it has any properties at all (which is a relation). In life there’s no such thing as “no stimulus” — that’s a stimulus, too — so you don’t need a special way in.

]]>