Content

Summary

This document provides information about the LDK2 protocol implementation for VSM.

Status of Driver	APPROVED
Component for Driver	GADGETSERVER
Release (Build) of Component	vsmGadgetServer Version >= 5.2.1.124 vsmGadgetServer Version >= 5.4.0.207
Revision of Implementation	1.0.0.2

Name/Type of 3rd Party API	Grass Valley LDK Connect Gateway XML
Version of 3rd Party API	Version: 2.0
Additional 3rd Party information

Connection

Connection Type	TCP/ IP
Default Port	8080

Supported Features

Control Camera/OPC/Basestation via gadgets. The exact functionality depends on the device.

The protocol reports a description of all functions that are available. From these descriptions, a gadget tree is being created which allows control of the devices. This version allows switching of the available Basestations/Cameras to the known OCP’s. While the devices are identified by their Device Id, all devices must be mapped internally. This mapping is writeable and is accessible via the web interface.

Supported Commands

AppAuthentication	Initial authentication request after a connection has been established.
DeviceInformation	Requests the description of a device.
FunctionInformation	Requests the function descriptions of a device.
FunctionValueRequest	Requests to change the value of a function.
FunctionValueChange	Reports an updated function value.

Configuration Details

If the switching feature is required, the protocol has to be mapped to an Ember+ or a Pro-Bel SWP-08 connection to use the Matrix. To disconnect a Camera from an OCP we need a Camera number which is not assigned to a Camera on the LDK Gateway network. The default number is 99 and can be modified via the Web UI.

vsmGadgetServer 5.2

A mapping entry has following format:

“LDK device Identifier:vsm-Identifier_Source/Target Index” e.g. “Stadion1:Camera_5”.

Since source 0(zero) is used as a disconnect, the source and target indices have an offset by 1. OCPs correspond to the matrix targets and Cameras to the matrix sources.

New devices with a yet unknown Device Identifier will generate new mapping entry e.g. “MyNewCam:Camera_11”. If the new camera is a replacement for an old one and should be used as the already configured Camera 5 the new entry can be modified to map the new camera to the configured one: “MyNewCam:Camera_5”.

The old mapping entry “Stadion1:Camera_5” must be deleted!

Please restart the vsmGadgetServer service if there were any changes on your Camera/OCP system.

Example:

Current configuration:

New camera has been installed:

Stadion1 camera has been replaced by MyNewCam and should be used as source 5:

vsmGadgetServer 5.4 (and 5.6)

The new version introduces a common mapping layout. If a protocol has an enabled mapping, the user can download the mapping as an xml file, edit the file and upload it again.

UI Controls:

GrassValley.LDK2.Mapping.xml:

The <identifier> tag represents the Device ID of a LDK device. So a device ID change will generate a new entry. The <index> tag represents the Source/Target index of the matrix and is used for the Ember+ identifiers.

In the case of LDK2 protocol a source is always a Camera and a target is always an OCP. To remap a renamed device download the xml file and edit the xml.

Example

An already known and configured Camera gets a new Device ID for some reasons, but should be used as the old source index in vsmStudio.

As we can see, the old value is still present in the mapping file.

A remap of new Camera “LDX80_New” from source 1 to source 0, can be done in just 2 steps.

Delete the old entry:
Replace the index value of the LDX80_New from 1 to 0:

Save the xml and upload it via the Web UI.

The mapping file must not be renamed, always use this format: GrassValley.LDK2.Mapping.xml.

Known Issues

All 0-99 values in GV Gui can be scaled. GrassValley: Values with unit attribute defined(db, %, etc.) should not be scaled.
It is not possible to set Var.Exp. Time in vsmStudio once Exposure Select is set to Var. But is is possible the other way round

GrassValley Camera Control