CDU screen blanking

[Hardy Heinlin]

Good evening,

as you all know, when you enter something into the CDU, the screen usually blanks for a moment.

I forgot how the system behaves when two or three CDUs have the same page selected. Well, the CDU you're working on will blank momentarily, but will the other CDU (which has the same page selected) blank as well?

I think it won't. It'll get the new data display a bit later, but it won't blank.

Does anybody know?


Regards,

|-|ardy


[size=8](In case you're wondering why I'm not asking our best man in the alpha team: He has left the project some weeks ago.)[/size]

[Mariano]

Hardy,

Sorry, can't answer your CDU question, but do you mean a certain person has left the project forever? Or is it a temporary leave?
You last sentence kind of stunned me.

Thanks,

Mariano

[Michel Vandaele]

As far I know, they are working completely independent, so I don't think the other will blanck at the same moment. Will check it any further with RL.
See you
Michel

[delcom]

The rest won't blank, new data comes about 0.2 sec later (edit: on the other CDU's).

regards,
delcom

[Hardy Heinlin]

Thanks! :-)

While we are at button pushing ... I also wonder how the ATC key behaves. I know, a short click opens a normal ATC page, while a 1 sec key hold opens a special ATC page. Now I don't know what generates the initial "click", is it the first button press, or the first button release? If it is the former, the normal ATC page will occur in any case, no matter if the key is clicked or held (when holding, the normal page will occur, thereafter the special page).

Any tips would be appreciated.


Regards,

|-|ardy


Edit: The same question for the CLR key (clear). Single click deletes the last character, holding 1 sec deletes the whole scratch pad. Is the initial click generated when CLR is pushed, or when CLR is released?  If the former is true, the  last character will be deleted in any case, no matter if the key is clicked or held (when holding, the last character will be deleted, then the whole scratchpad will disappear).

[delcom]

It's a general rule. First PRESS executes the first command asigned for the key, additional 1 sec HOLD does the second command (if there's any). You've guessed it right with both ATC and CLR, sitting on the key executes both functions.

regards,
delcom

[Hardy Heinlin]

Yes, but how do you define "PRESS"?

Example: Hold the button for 0.2 sec. (not 1.0, but only 0.2)

Slow motion film:

sec 0.00 : Contact is open
sec 0.01 : Contact is closed
...
sec 0.19 : Contact is closed
sec 0.20 : Contact is released

Will the initial signal be generated at sec 0.01 or at 0.2 ?


Thanks,

|-|ardy


Another example:
If you click with your mouse on the POST REPLY switch on this web site, the switch will fire only when you have released your mouse button. It will not fire when your mouse button contact is closed, but only when the contact is released.

[delcom]

It happens at 0.01 sec.

EDIT: lol, Hardy...I got your drift.

[Hardy Heinlin]

OK, that agrees with my model :-)

When I'm holding my CLR key, the last character will be deleted before the whole scratchpad disappears.

While holding, I can't blank the whole entry without deleting the last character first.

|-|

[John Golin]

The rest won't blank, new data comes about 0.2 sec later (edit: on the other CDU's).

regards,
delcom

I was reading this and wondering as it's not clear to me - so I thought I might post to be on the safe side...

Is it ;

a) CDU blank starts, + 0.2 seconds other CDUs update, time passes, CDU blank ends.
b) CDU blank starts, time passes, CDU blank ends and other CDUs update
c) CDU blank starts, time passes, CDU blank ends, +0.2 seconds then other CDUs update
d) None of the above, get back in your box John!

[Hardy Heinlin]

Hi John,

before Delcom gives you the final answer -- I think we have two time values here:

1. Blank time of your onside CDU

2. Time until the other CDUs are updated

These two times are not linked and are not equal, as far as I understand it. I have seen screens where even on the onside CDU itself the blank time was over before the new value was displayed, i.e. the screen blanked, then unblanked and the old value was still displayed, then the new value was displayed (a fraction of a sec later).

The update time may be shorter or longer than the blank time, I guess the update time is random and the blank time is fixed and it's main purpose is simply to give the pilot a visual feedback that a button has been pushed.


Cheers,

|-|ardy

[delcom]

John,
sorry...I've sent all those previous messages from my phone, hence the short (and easy to misunderstand) sentences.

Correctly: CDU blank starts, time passes, CDU blank ends, 0.2 seconds later other CDU's update (including RCDU).

delcom

[delcom]

OK, that agrees with my model :-)

When I'm holding my CLR key, the last character will be deleted before the whole scratchpad disappears.

While holding, I can't blank the whole entry without deleting the last character first.

|-|

Yes, Hardy...that's exactly how it is.

(I don't need to mention, that let's say a 0.8 sec "press" is not a HOLD yet, so only the last character would be deleted).

d

[Hardy Heinlin]

Delcom, do you have the impression that the blank time is always the same on all pages and functions?


|-|

[delcom]

I think there are quite a few different duration of blanks.

d

[Hardy Heinlin]

Yes, I just noticed some pages do not blank at all ...

[Peter Lang]

I think there are quite a few different duration of blanks.

d

A friend of mine, who is on CLX answered tonight:

The time how long the CDU blanks depends on what you are doing. But it is almost a second.  E.g. if you are in the Route Page and enter a routing the blank time after entering an airway is "felt years"

And it only affects the CDU where the entry is made.

It happens quite frequently, that if everybody enters something in his CDU simultaneously the system crashes and the -Resync FMC Msg- appears.


Hope this helps
Peter

[Michel Vandaele]

After info from my RL friend, I can confirm what Peter is saying.  
He also noted that in normal operations the middle CDU normally will never be on the same page as Capt/FO cdu as it is only used for ACARS or by maintenance.
B. Rgds
Michel

[Hardy Heinlin]

Thanks!

My idea that this be just a visual feedback was obviously wrong. (The more I get into it the more I recall now ...).

The individual blank durations are easy to model, it is actually already prepared in PSX. I just need to enter a time value in the respective function. I guess I will guess them ...

The same for the sync time ... I just need to enter a value. No prob.

I think when the message "Resynching other FMC" occurs, the system has not crashed, it was just too slow with the synching. It is synching all the time. Are the same old computers installed nowadays? I recall they had 16 bit and max 1 MB of RAM (aside from the additional redundancy features).


Cheers,

|-|ardy

[Jeroen Hoppenbrouwers]

From what I know...

The blanking time is linearly related to actual FMC number crunching. You can pretty much predict what will take long and what won't.

As soon as the FMCs detect that they do not have the exact same data, which can easily happen if two crew members enter data simultaneously, they decide to throw away the memory of the slave and reload it from the master FMC. This is a different process than the continuous data comparison or occasional data update (when one FMC receives new data from the onside MCDU). If you see this message, you know you have upset the system. If you do this often enough, the machines will go to a cold start which means you have to re-enter everything from scratch.

There's a good reason why Boeing/Honeywell don't recommend both crew members to finger their keyboards at the same time. However, if one of the pilots only switches page, it is not really dangerous.

PSX must be as sensitive to this as the real thing, of course. You MUST remove some of your critical section protections that you have so carefully constructed   :twisted:

Jeroen