AN2012-11 Cue Encoding HSI12

GEP100 - HEP1003Gb/s, HD, SD embedded domain Dolby E to PCM

decoder with audio shuffler

A ® product

COPYRIGHT©2011 AXON DIGITAL DESIGN B.V.

ALL RIGHTS RESERVED

NO PART OF THIS DOCUMENT MAY BE REPRODUCED IN ANY FORM WITHOUT THE PERMISSION OF AXON DIGITAL DESIGN B.V.

3Gb/sUpgradable to

EmbeddedMetadata

S2020

Quad speed

Cue encoding and decoding

Cue tone encoding and decoding with the HSI12 module

A ® application note

COPYRIGHT©2012 AXON DIGITAL DESIGN B.V.

ALL RIGHTS RESERVED

NO PART OF THIS DOCUMENT MAY BE REPRODUCED IN ANY FORM WITHOUT THE PERMISSION OF AXON DIGITAL DESIGN B.V.

EMBEDDED AUDIO PROCESSINGEMBEDDED AUDIO PROCESSING

page 2


It is often necessary for broadcast operations to send simple commands to remotely located equipment. Common examples of this are to signal when cable head-end systems should insert local advertising (known as Opt-Out avails), to indicate when local Newsrooms should opt into a network feed or to instruct transmitters to switch to a alternate feed.

Sometimes it is also a requirement for the central broadcast operation to receive signaling from another location. For instance an OB vehicle may want to trigger the central Playout Automation System to insert a commercial break into the live program feed.

There are several possible methods of generating and carrying signals to/from remote locations; an original approach was to generate audio cue tones and send these over a separate audio circuit or an audio channel associated with the program video. This method was reliable but the reaction time of the decoders often meant that the system was not frame accurate. The name, however did stick and the process of sending triggers, whether using audio signals or not, is often called Cue Tones.

An approach commonly adopted by broadcasters to convey simple triggering signals between one location and another is to use spare capacity within the video signal, the VBI in SD signals and VANC in HD. The triggers are encoded as a data packet and carried along with the video signal; with this

method the triggers do not occupy an audio channel and triggering systems are capable of being frame accurate.

The data packets need to be capable of passing through video processing equipment such as Frame Synchronizers and telecommunications circuits. Teletext is the most widely used carrier for SD operations, with only a single video line being required to carry a robust signal containing 6 triggers. Similarly an OP47 data packet can carry 6 trigger signals in HD systems.

In both cases the trigger signals can successfully be carried over compressed satellite and terrestrial links.

Normally Teletext data packets carry information relating to particular page, with many packets being required to make-up a whole page, e.g. page 199, which is commonly used for carrying the menu page for an on-screen data service, may require 25 separate packets to form a whole page. These “normal” packets cannot carry ad-hoc data which is not associated with a designated page.

There is, however, a specific Teletext packet, Packet-31, which is defined as page independent and can be transmitted at any time without affecting the correct operation of the basic Teletext service. It is this packet type which is used to carry Cue information

Introduction

Example 1: Cue Tone system to trigger insertion of local content at cable head-end

Outside Broadcast or RemoteStudio

Cue Tone Generator

NetworkVideo

“Local avail” GPI from Automation

or Operator

Cue Tone Decoder

Local Distribution

Local Video

Cue Tone Generator

Studio/ OB Video

Commercial Break GPI from

Operator

Cue Tone Decoder

Network Video

Automation

Presentation System

Video Server

Outside Broadcast or RemoteStudio Broadcast Center - Playout

Cable Head-end


page 3


Within the Synapse range is a dual function Cue Trigger encoder/decoder module – HSI12.

The HSI12 uses Softel’s proven Oliver Cue technology to encode 6 GPI inputs as either Teletext (SD) or OP47 data (HD) and embed it onto a SDI stream.

The HSI12 module can also be used to de-embed the data from a SDI stream and drive GPOs on a GPI16 module.

Because the HSI12 uses technology compatible with the SE3067 Oliver cue system it can both encode cues for legacy equipment to decode, or decode cues originating from an existing system. The HSI12’s rear I/O panel (model number BPH04)

has a HD15 D-Type connector, connecting the relevant GPI line to Ground will cause a trigger to be generated.

The HSI12 utilizes the GPI16 module to provide output GPI (GPO) connections. Communications between the modules uses either the Synapse Bus where one HSI12 communicated directly with an adjacent GPI16 module or it uses Synapse Event Messages which travel across the back-plane of a Synapse frame. This allows multiple HSI12 modules to access a single GPI16 located within the same frame.

Details of the configuration of the HSI12 and GPI16 modules for both modes of operation are given below.

The HSI12 module

Example 2: Cue Tone system used to trigger a Playout Automation System from a remote studio or OB vehicle

Outside Broadcast or RemoteStudio

Cue Tone Generator

NetworkVideo

“Local avail” GPI from Automation

or Operator

Cue Tone Decoder

Local Distribution

Local Video

Cue Tone Generator

Studio/ OB Video

Commercial Break GPI from

Operator

Cue Tone Decoder

Network Video

Automation

Presentation System

Video Server

Outside Broadcast or RemoteStudio Broadcast Center - Playout

Cable Head-end

HSI12

INTERNAL SYNAPSE BUS

RACK CONTROLLER

HD/SD-SDI IN 1

HD/SD-SDI OUTPUT

GPI IN

EQ

HD/SD-SDI OUTPUT

MONITORHD/SD-SDI OUTPUT

ETHERNET

CUE TONE(PACKET 31)

DECODER

SOFTEL VFLEX POWERED

CUE TONE(PACKET 31)

ENCODER

PREVIEW CVBS OUTPUT ENCODER

CVBS


page 4


Cortex control screen for HSI12 showing X31 (packet 31) configurationX31-Cues: Controls insertion of X31 data On/Off

Packet Format: The data carried in packet 31 can be encrypted to prevent unauthorized detection and changes, or Plain-View allowing the data to be viewed by a standard Teletext decoder.

X31-Ln: Selects the line on which the X31 data packets will be inserted in a SD signal

X31-Data: If Packet Format is set to Plain-View (unencrypted) user definable ASCII text can be included in the data packet. For example it could show the Channel Name of the source of the SDI stream.

Channel: Used with “Address” to form the ID of the sending unit, the decoder has to set to the same value for successful exchange of trigger information. Note the default Channel = B, this is the value required for the HSI12 to be used with legacy triggering equipment

Address: Used with “Channel” to form the ID of the sending unit

The HSI12 configuration

Cortex control screen for HSI12 showing the HD inserter configurationHD Transmission: Controls insertion of OP47 data into a HD-SDI stream. This can also be set to OP47-split. In OP47 split mode the original field dependencies of the SD data (ANC packets etc.) that is being carried is preserved.

Field 1/2 Line: Selects the line(s) in the HD-SDI stream where the trigger information, contained in OP47 packets, will be inserted

HSI12 and GPI16 Configuration for Output Trigger GPIs (GPO)The HSI12 does not have local General Purpose Outputs (GPO) connections, when the HSI12 is configured as a trigger decoder and physical outputs are required these can be provided by a GPI16 module.

GPI16 modules can be configured to operate in one of two modes; MasterCard where it is directly associated with a single HSI12 module located next to it or Frame mode where Synapse Event Messages are used to communicate between HSI12 modules located in any slot and a GPI16 module in the same frame.

Configuration of HSI12 and GPI16 in Master Card modeSynapse frames have a patented inter-module connection system called Synapse Bus, this is

commonly used to link audio Add-On modules to video MasterCards.

In this application the HSI12 is the MasterCard and the GPI16 receives the GPO information via the Synapse Bus.

The GPI16 module has to be located in the frame slot directly to the right (as viewed from the front) of the HSI12 module.

The GPOs are connected on a 1 to 1 basis, for example when GPO1 is active on the HSI12 module GPO1 operates on the GPI16.

The information passes directly between modules with no intermediate processing so GPI timing is repeatable.


page 5


Cortex control screen for GPI16 showing the GPO configurationSource: MasterCard configures the GPI16 to directly communicate with the HSI12 module directly to the left in the frame.

GPI Input Mode: Defines if the relay latches or is non-latching. For normal operations this should be configured as Non_Latch

Debounce: Provides debouncing of the mechanical relay outputs

GPO Configuration: In MasterCard mode the module has a simple 1-to-1 relationship with the GPI information received from the HSI12 module and therefore Card = All Cards and Tag = 0

Default: OFF = The relay is connected to the Normally Closed NC contact. The module can be configured such that the relay common is connected to the Normally Open NO contact by default, the achieve this Default should be set to On.

The HSI12 configuration

Configuration of HSI12 and GPI16 in Frame modeA GPI16 module has 16 output relays, these can be shared by a number of HSI12 modules using data messages, called Events, sent via the Synapse frame’s internal communications bus.

Event messages are asynchronously generated on a card and not in response to a request, the aim of Events to inform the environment about a change of condition on the card, in this instance they are used by the HSI12 module to inform the GPI16 that a trigger has been received.

Each Event message is made up of: ▪ A message string to indicate what has happened,

for example “GPO_ON-1” , ▪ A Tag which is a numerical value representing

the text string e.g. GPO_ON_1 = Tag 52, GPO_OFF_1 = Tag 180 (52 + 128).

▪ A priority between 1 and 255. Priority 0 is message disabled

▪ The slot number of the originating card.

The values for the Tags associated with the 6 GPO on the HSI12 are given below.

HSI12 Event Message tag values for GPOFor each GPO relay output the GPI16 module requires information about which slot in the frame the HSI12 has been installed in and to which relay the GPO should be assigned too.

The HSI12 module also requires a configuration to enable it to send event messages to the GPI16.

When used in this mode a single GPI16 module can receive GPO trigger information from more than one HSI12 module. Also more than one GPI16 module can be installed, therefore two GPI16 modules could be used to provide the physical connections for five HSI12 modules

Output GPO Off GPO OnGPO1 180 52

GPO2 181 53GPO3 182 54GPO4 183 55GPO5 184 56GPO6 185 57


page 6


Cortex control screen for HSI12 GPO messagesSelecting the box next to the GPO number enables the event message to be sent on the frame’s communication bus.

Cortex control screen for GPI16 showing the GPO configurationSource: Frame configures the GPI16 to listen for Event messages from cards in its local frame

GPI Input Mode: Defines if the relay latches or is non-latching. For this use it is normal to configure the relays to be Non_Latch

Debounce: Provides debouncing of the mechanical relay outputs

GPO Configuration:

Card: Selects the Slot in which the HSI12 is located which will control the specified GPO relay. This configuration shows that GPO relays 1-6 are to react to Events from the HSI12 in Slot 1 and GPO relays 7-12 react to Event messages from the HSI12 in Slot2.

Tag: Defines which of the six GPO event messages will activate the relay. In this example GPO 1 will turn on when an Event message with Tag 52 (GPO_ON_1) is detected from the HSI12 in Slot 1. Because the GPI16 is configured in Non_Latch mode it will turn off again once the message has cleared.

Documents

AN2012-11 Cue Encoding HSI12