Blackout Bug: Boeing 737 cockpit screens go blank if pilots land on specific runways
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.
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.
Join Date: Oct 2001
Location: UK
Posts: 98
Likes: 0
Received 0 Likes
on
0 Posts
Originally Posted by MechEngr
It should have an independent watchdog timer processor to automatically reboot if there is a fundamental software failure, but maybe only the thread/task/subsystem to update the displays failed and the watchdog reset and all other controls is still running
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.
Join Date: Apr 1998
Location: Mesopotamos
Posts: 5
Likes: 0
Received 0 Likes
on
0 Posts
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.
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.
Originally Posted by MechEngr
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?
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
Originally Posted by MechEngr
Maybe SKLM is an unreliable narrator.
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°.
Join Date: Apr 2019
Location: EDSP
Posts: 334
Likes: 0
Received 0 Likes
on
0 Posts
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°
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°
Join Date: Jan 2011
Location: Seattle
Posts: 694
Likes: 0
Received 0 Likes
on
0 Posts
Originally Posted by MechEngr
The 737 is rumored to be running an 80286 processor which is a well understood design.
*One of the reasons Linux and other true multitasking systems had to wait for the '386.
Originally Posted by visibility3miles
If it has a serious bug, it's better to have the screens go blank than provide erroneous information.
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.
Join Date: Nov 2006
Location: UK
Age: 34
Posts: 141
Likes: 0
Received 0 Likes
on
0 Posts
Originally Posted by Uplinker
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.
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.
Join Date: Apr 2008
Location: back of beyond
Posts: 115
Likes: 0
Received 0 Likes
on
0 Posts
Originally Posted by Uplinker
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.
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.
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?
Join Date: Nov 2019
Location: USVI
Posts: 4
Likes: 0
Received 0 Likes
on
0 Posts
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.
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.
Join Date: Apr 2019
Location: EDSP
Posts: 334
Likes: 0
Received 0 Likes
on
0 Posts
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.
