CDU screen blanking

[Peter Lang]

Hi Hardy,

the answer from my friend to your question, which I copied and pasted in my mail to hin, clearly says yes.

I just checked the older mails from him concerning this topic. He said, the screen almost blanks upon every entry. Only the time depends on what your are doing.

If I remember right, he also told me when I met him some weeks ago, that over the Ocean they better do not touch the keys. And if necessary only one pilot does, to avoid a CDU crash.

These parts really seem to have very old processors and therefore work rather slow.

I will check some of my 747 videos. Perhaps these sequences are shown.

Peter

[Jeroen Hoppenbrouwers]

If I remember right, he also told me when I met him some weeks ago, that over the Ocean they better do not touch the keys. And if necessary only one pilot does, to avoid a CDU crash.

WorldFlight 2010 will be an interesting one...

[Pierre Theillere]

Hi guys!

I don't know if the "old" CRT MCDU, and the "new" one behave the same manner regarding page blanking. But I have the ITVV video of the B744 flight from EGLL - KSFO (Virgin 19 I think) in an "old" B744, and I hope I can find some down-selections examples during the time they play with the MCDU, near the end of the flight.
I don't think in the Cathay 250 video (also from ITVV) they're playing enough with the MCDU. In the B777 they do (mostly in the sim), but there seem to be huge differences (regarding MCDU) between B744s and B777s.
Will keep you informed on what I manage to sort out from those... later this week!

[Peter Lang]

But I have the ITVV video of the B744 flight from EGLL - KSFO (Virgin 19 I think) in an "old" B744, and I hope I can find some down-selections examples during the time they play with the MCDU, near the end of the flight.
I don't think in the Cathay 250 video (also from ITVV) they're playing enough with the MCDU.

In the Virgin Video, (before descent - easy to find within the menu) the CDU is described and there are some good impressions about the duration of the blanks. But no scratchpad entry as Hardy described is shown.

In the Cathay Video no CDU blanking is to be seen. But I saw another interesting blanking and delay on the speed tape during flap retraction.

The Oasis and Polar videos I still have to check.

Peter

[Will]

Is Kim still around?  If he checks the forum, Hardy (and hopefully us, too) could give him lists of things to check in flight.  Oh, wait, did he move to the 767?  I forget.

[Walter Kranl]

If I recall correctly, Kim moved to the A320.

Walter

[Hardy Heinlin]

Kim is in the Alpha team, but too busy with other things these days.

|-|


[size=8]P.S.: Our best man is back :-)[/size]

[Will]

Hey, that's good to hear! I hope he's healthy and happy, too.

[delcom]

Hi Hardy,
If I remember right, he also told me when I met him some weeks ago, that over the Ocean they better do not touch the keys. And if necessary only one pilot does, to avoid a CDU crash.

During test flights we have at least three guys punching the three CDU's simultaneously like if there was no tomorrow. Only the option code is changed temporarily which does NOT (or shouldn't) effect the good old SDP-185 CPU performance. Personally, I've never seen a "CDU crash". Operating the fourth (R)CDU  shouldn't give any headache neither.

cheers,
delcom

[Jeroen Hoppenbrouwers]

Delcom: many people do not make a difference between a "CDU crash" and a "FMC crash" and a "FMC resync" and all other abnormal modes the system can get into. I would not be surprised to learn that many cases of reported "crash" actually were logical and natural attempts of the machinery to assure 100% correctness.

Like, if you enter two data items on the same page but using different CDUs, both FMCs will be out of sync for half a second as they both get their data first and therefore have a different state. Then the master will dump its memory over to the slave to assure that they both are exactly on the same track -- else there is no point in comparing their calculations all the time. Right?

It is mostly caused by the redundant design, where there is no single point of failure. You need these single points to assure sync in all cases, so 100% cannot be achieved with this design unless you resync when possibly needed.

I wonder whether more modern designs still have the same approach.

Jeroen

[delcom]

Ahhh I see, that explains it. Thanks Hoppie.

regards,
delcom

[Jeroen Hoppenbrouwers]

That is, if I am correct.

I bet I am correct about many people not totally understanding the difference between CDU and FMC, and between resync and warm start and cold start.

I am not sure about my interpretation of exactly how you can force a FMC resync (i.e., by entering two different data items using two CDUs on the same FMS page).


Jeroen

[Hardy Heinlin]

If I recall correctly (I'll have to study a bit more in the next days), the sync mechanism is not symmetric, but the left FMC (or CDU?) is the master. Inputs from the right device will first go to the left one and evaluated; from there it'll be forwarded to both FMCs. Something like that. If I'm saying left device, it's probably the left CDU, not the left FMC.

|-|

[Jeroen Hoppenbrouwers]

Will PSX offer a few non-standard rewiring options between the CDUs and the FMCs so that we can test different configurations?    :mrgreen:

[Hardy Heinlin]

Not in this particular case, Sir :-)

[Will]

This discussion has made me think about software glitches in FMCs... I can see the utility of modeling things like this in the simulator, because it could train pilots in the recognition of non-standard instrumentation behavior.  The problem is that all users of PSX would assume the behavior was due to a programming error, instead of a simulated condition.  (I recall the funny posts from time to time on the old board about "I found a BUG... all of a sudden the screen went totally gray and I could barely see the instruments.")

Same deal with simulated failures of ground-based NAVAIDs.  Picture this... the conscientious pilot is on the final segment of a long trip to Kuala Lumpur, and tunes the ILS only to find no signal.  No Morse code identifier, either.  How many pilots quit the sim and report a bug, vs. decide to work around the simulated failure by flying another approach?

[Jeroen Hoppenbrouwers]

... let alone the many planned CORRECT simulations of real plane equipment which is at times rather illogical, and often mistaken for a BUG!!!1!!.