Sierra Video Sequoia Family - Manual (Page 54)

SIERRA VIDEO SYSTEMS
48
The delayfields argument of this command takes into account the hardware delay. So, if a router
has a minimum delay, including the hardware delay, of one full field, as described in the previous
paragraph, then a delayfields value of 1 causes this minimum delay to be used. A delayfields
value of 0 will also cause this minimum delay, because the router uses its minimum if a smaller
value is specified. A delayfields value of 2, however, will add one more field to the minimum
possible delay. Thus, delayfields specifies the number of full fields of delay between end-of-
crosspoint-command-string-received and crosspoint-switch-occurs. Note that the actual minimum
value of delayfields depends on the particular router model.
Routers typically have a limit to the number of crosspoint commands they can process in one
field. First, there is an inherent delay in sending the command to the router, but beyond that, the
router requires time to parse the command and buffer up the crosspoint data, plus it requires time
to deliver the buffered data to the hardware when the desired video field arrives. Each individual
router has documentation to describe its limitations on how many crosspoints it can process in a
given amount of time.
Larger values for delayfields give the router more time to process commands. Although the long-
term average number of crosspoints that can be processed per unit of time is unchanged, a larger
delayfields value can improve router performance during a short burst of many crosspoint
commands. For example, suppose a large number of crosspoint commands is sent to the router
in a single large command. If delayfields is small, the router typically wonít have time to parse and
process all these crosspoint commands and place the data in the crosspoint delivery buffer
before the target video field arrives. By making delayfields larger, the user can give the router
more time to process the crosspoint commands.
If too many crosspoint commands are received and the router is not able to process them fast
enough, it will output the crosspoint connections as soon as it can. Unexpected delays in
crosspoint output are a sign that the router is being pushed beyond its limits.
The fielddelay value applies to the entire router, not just to the control port on which the “F”
command is received. It is therefore recommended that a single value be settled on for the
fielddelay value, rather than changing the value constantly depending on needs. Once changed,
the router records the value in non-volatile memory and uses it each time it is powered up, so it is
only necessary to change it one time.
Even though a crosspoint isnít changed until the fielddelay time has elapsed, the router records
the new crosspoint state immediately upon receiving the crosspoint change request, so a
controlling device may receive a report of a crosspoint change before the change has actually
taken effect, and this is more likely to happen the larger fielddelay is. Since routers currently
make no guarantees about when they will report a crosspoint change anyway, this behavior is
usually of no concern. There is a case where this could cause problems. If the fielddelay value
were to be changed while two different devices were changing the same output, it is possible for
the router to report the incorrect input value for that output. This would happen if the earlier
device that changed the output did so before the fielddelay value was changed, and the later
device that changed the output did so after the fielddelay value was reduced but soon enough
that its input value would be sent to the crosspoint hardware before that of the earlier device. A bit
later, the earlier deviceís input value is sent to the crosspoint hardware, but the router has
recorded the later deviceís input value as being the one in effect. To prevent this scenario, we
recommend that an appropriate fielddelay value be chosen, set, and left alone.
Here is an example of an “F” command:
** F5 Y1,5 X2,6,3 !!