That's even weirder. How can there be significantly different values for a fundamental measurement? Tiny fractions of a degree are one thing, but 2 degrees? I guess the two airports aren't going to have automated landings so a couple of degrees isn't a problem, but this seems like purposeful misinformation in comparison.

Anyway, if the the values they are using are from the same source as yours, then rounding to the nearest 0.1 degree would set them to 270.

That still loops around to why the software to having a problem. The reverse approaches are 0 degrees true, and 0 is just as problematic for trigonometry as 180 is. I can see where the opposite problem would be more likely to exist - a database of the lat/long coordinates for each end and a failure to determine the correct arctangent, but the ones I looked at aren't exactly 270 so the arctangent should not be infinite nor zero.

Puzzling.

The fact that "all six DUs stayed blank until a different runway was selected" suggests it wasn't dead, just thinking.

I recall a widely-distributed maths library function that could take literally years to execute with certain near-zero inputs. Could be something like that.

Didn't a squadron of F22s (7 I recall) have their screens "dump" when they all crossed the international dateline.
No doubt the word "dump" (probably refers to OS dump) which is now a common term in FJ territory which will probably also become standard in civvie street.
And to think some are espousing autonomous flight using these very same software developers.

At least it's reproduceable, that is a big head start over something intermittent.

Your guess is as good as mine. :O

The link you supplied for SKLM shows the same latitude for both thresholds. If somebody can explain to me how two points with the same latitude and less than a mile apart can have a relative bearing other than due east/west (unless they're close to the N/S Poles) then I'd be extremely grateful.

Or just plug those provided threshold values into any GC calculator, such as https://www.cactus2000.de/uk/unit/massgrk.shtml

Maybe SKLM is an unreliable narrator.

Other random samples on the same site show fairly consistent runway heading errors, best seen on airports with long runways (London Heathrow, for example).

As an alternative to GC calculators, a quicker way to get a reasonably precise true heading for a runway is simply to use the ruler on Google Earth. For example EGLL 27R is oriented at 267.3° true, according to the above website, whereas the actual value is 269.7°.

https://cimg5.ibsrv.net/gimg/pprune....e0885ed668.jpg

Embedded processors can usually be configured regarding their behaviour if a division/0 occurs - ignore or trap,dump and reset. When you choose later option and feed them the same div/0 after restart they would be trapped in a reset loop until you remove it which seems easy in this case but is difficult if you read the 0 from memory.
Therefore we would not do that at the expense of having a not well defined state if a div/0 occured.
Least significant bit of a heading representation in 16bit signed integer would be 0.0109866°

If it has a serious bug, it's better to have the screens go blank than provide erroneous information.

This might be a part of the problem. The '286 isn't quite adequate to support fully multitasking operating systems. The memory management hardware isn't quite up to snuff*. So whatever O/S the DEUs are running, the failure of one process thread can hang the entire system.

*One of the reasons Linux and other true multitasking systems had to wait for the '386.

What, ALL the screens? - leaving you with just the standby instruments and nothing else?

I disagree. A navigation problem alone should not blank the attitude, IAS, TAS, altitude, V/S, A/P status, A/THR status, N1, EGT, etc, etc. You should just get a red flag for; heading, G/S, wind vector, ILS, VOR, map, compass, course, or whichever Nav function is unavailable, or disagrees with the other side. The whole bloody screen shouldn’t blank, nor should the screens which don’t display any Nav info.

That’s one serious bug if the whole panel screens go blank! Would love to see a sim video with it re-produced.

I have problems understanding how a fault in the nav data or its processing can cause displays to blank. I always understood from the various schematics that the Flight Management Computers, Flight Control Computers and Display Processors are physically separate boxes connected by a data bus. In this case the displays should only get turned off if they received an "off" command - surely loss of signal from a crashed FMC should produce an error display rather than a blank screen?

On the other hand if the boxes on the schematics represent logical components run on the same hardware, the plot thickens. What else stopped working when the displays blanked?

Perhaps someone in the know can chip in?

Well, in programming procedures, we have to deal with the legacy code, and code that exists. The lookup feature in the coding will take you to the next line. It is always not where you want to be. This is why we test the new code as much as we can.
that being said, there will always be certain inputs that will cascade to unintended consequences. I have sen many. many strange sequences in the coded flightpath, mostly in the flyby vs flyover code. I have seen, under certain flightpaths, where the AP is locked on, and no matter where you try to disengage, that internal command locks the 1 and 0 to 1, ie on.

best advice is to always report these anomalies, with the combinations thereof.....

All that being said, it is very easy to see how this happened, sorry it got to the flightdeck, but, well damn.

From the limited information freely available, there are two DEUs providing data to the six displays. Now if both DEUs are fed with coordinates to display the same runway on a nav screen, causing a powerlatch because they trigger some exeption, six blank screens is what you would expect.

Sounds reasonable, thanks. I wasn't thinking of the bug being in the DEU's.