YVP Protocol

From YSTV Documentation Wiki
Revision as of 22:28, 12 July 2012 by Sam.nicholson (talk | contribs) (Wrote the YVP protocol documentation)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

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:

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

Here XX and ZZ refer to outputs, and YY, AA refer to their linked inputs. Depending on the device, a zero on the input refers to input zero or not mapped.

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