Grass Valley Switcher Products - Manual (Page 29)

Switcher Products — Protocols Manual29
Kalypso & Zodiak Contribution Tally Protocol
This routine looks for two consecutive characters greater than 128. The
message type is extracted from the 4 most significant bits of this character.
An instance ID is extracted from the 4 least significant bits of this same
character. Instance IDs indicate specific information for identical objects
(e.g., MEs). The meaning of instance (if any) for a command is indicated in
the command descriptions above.
Each message type has a known message length. messageLength returns
the number of data characters in the message. Message data lengths are
specified in the command descriptions above.
Characters are assembled in a buffer including the message code and
instance ID. When all characters have been received, copyTally is called
to move the completed message out of the message buffer to somewhere it
can contribute to tally calculations.
This algorithm assumes the program keeps track of valid receipt of each
and every contribution tally data block (every instance of all messages). It
is not appropriate to process tally data if all data blocks are not up to date.
When a data block is received, it is marked as valid (possibly by
copyTally
). The only thing which invalidates any data block is
invalidateAllData which invalidates all data blocks. This only occurs
on loss of communication or when the switcher sends the Initialize mes-
sage.
allDataValid is routine which checks all the data block flags to make
sure all the data is valid. If it is, tally calculations can be performed. If not,
they must wait until all blocks have been received. Since the switcher sends
a Data Consistent message after every background update and after a
stream of changes, this is the appropriate time to check the data flags and
determine if processing should be permitted.
processTally is routine which performs the desired tally calculations.
An alternative is to perform tally calculations in a different part of the
program but only if dataConsistent is true. Specific tally calculations
depend on the application and are beyond the scope of this document. In
practice, you wouldn’t need both dataConsistent and processTally.
Failure of the communications link for even a short period of time may
allow tally updates to be missed and the receiver’s view of the data to be
out of date. For this reason, some mechanism (represented by
onSerialTimeout
( )) should be implemented which detects lack of com-
munication activity. If this occurs, tally calculations should be suspended
and all data blocks should be marked as invalid. Tally calculations can
resume after all data blocks have been refreshed and a Data Consistent
message has been received.
At least one background update will be sent on a regular basis. The fre-
quency of this update is a function of the link baud rate as shown in the
table above. The inactivity timeouts listed in the table are based on 120% of
the update sequence length for 50 Hz operation (since it has a longer field
time (20 mS)).