YVP Protocol

This page covers an idea. It may not reflect current practice, but might help develop it.

YVP Protocol or YSTV Vision Path Protocol was part Mike Chislett's dream of controlling all the video routing in the station from one central unit. It describes a uniform system to communicate with crosspoints (the posh word for a mux) and eventually other devices as well. The protocol is based on something like butchered XML, in the present iteration each command is six characters long (except sometimes when a comma gets included, making it seven). Each command starts and ends with an angle bracket and should contain four more meaningful characters. Each command should be followed by a newline, although some devices don't implement this very well yet.

Commands

At present every device should implement the following status commands:

• <stat> This should provide the device status, see the format below.
• <help> Some human-readable help if the device is being used by a person for testing rather than by an automated software system, which should at least contain a sample mapping command

In addition, more helpful devices also implement (somewhat optionally):

• <init> Perform any first-use setup, in the event a fresh microcontroller has been inserted and never been set up before, should also reset the device to a default state.

Mapping Commands

Commands mapping inputs onto outputs should take the form <XX,YY> where XX represents the zero-indexed input, and YY the zero-indexed output. This should immediately cause action to be taken, and optionally the controller to return the output of a <stat> command.

Identity Response

At startup, each device should output an identity string to identify itself to the controller, looking rather like:

<d>DeviceName</d>
<id>IDNumber</id>
<v>Version</v>
<c>Baud Rate</c>

The IDNumber currently has no firm structure, something like a GUID would make a lot of sense. It should be unique to every device, while there can be several devices, for example 8x8 matrix switches with the same DeviceName, they should all have a unique IDNumber. Version is up to the author of the software, but ought to tie up to some kind of version control, and the Baud Rate is somewhat redundant but still in the spec.

Status Response

The command <stat> should return a response of the form:

<map>
<link>XX,YY</link>
<link>ZZ,AA</link>
...
</map>

Where the map tags indicate a routing table, and the link tags indicate a single link from that routing table.

In the above example, XX and ZZ refer to inputs, and YY, AA refer to their linked outputs. As zero-indexing is not used (for human readability) in YVP, a Zero on the input will refer to "OFF" for binary or numeric events, or "high impedance" for signal routing events (used in vision router linking to obtain larger matrixes). This won't actually lead to contention, as OFF and High impedance will have the same effect in routing - not driving the specified output (YY or AA in this example). The output number (YY or AA here) must be a positive integer, in the range 1 to 99 inclusive. It is naively expected that YSTV will never have more than 99 inputs or outputs in a single device.

Invalid Command Response

If an invalid command is received, the controller should respond <badc>

YVP Devices

• The Main Mux - Does not require a newline at the end of commands, nor a comma in mapping commands
• Tally (Roxanne) - Implements the init command, and zeroes indicate not mapped