SCANTER LAN Video Protocol

Software Interface Specification

CHANGE ORDER/REVISION
CO: APVD: CM: REV: CO: APVD: CM: REV. CO: APVD. CM: REV: CO: APVD: CM: REV:

Proprietary and intellectual rights of Terma A/S, Denmark, are involved in the subject-matter of this material and all manufacturing, reproduction, use, disclosure, and sales rights pertaining to such subject-matter are expressly reserved. This material is submitted for a specific purpose as agreed in writing, and the recipient by accepting this material agrees that this material will not be used, copied, or reproduced in whole or in part nor its contents (or any part thereof) revealed in any manner or to any third party, except own staff, to meet the purpose for which it was submitted and subject to the terms of the written agreement.
PREP

MLH MLH

CHKD

CHR IRH

APVD

CM

DATE OF INITIAL RELEASE TITLE

06-05-29

DATE OF THIS RELEASE

06-05-29

Terma A/S Headquarters Hovmarken 4 8520 Lystrup Denmark

Cage Code R0567 DOCUMENT NO. REV PAGE

SCANTER LAN Video Protocol

Template: Multipage5LevelCO-REV /Ref doc: 200000-AS

304124-SI

1 OF 8

Record of Changes Description Released. Changed RANGE from centimetres to metres Rev A B Date 06.03.02 See page 1

The use and/or disclosure, etc. of the contents of this document (or any part thereof) is subject to the restrictions referenced on the front page.
TITLE DOCUMENT NO. REV PAGE

SCANTER LAN Video Protocol

304124-SI

2 OF 8

Contents
1 1.1 2 3 4 5 5.1 5.2 5.3 6 7 INTRODUCTION................................................................................................4 Scope.................................................................................................................4 REFERENCED DOCUMENTATION ..................................................................4 INTERFACE PROTOCOL REVISIONS .............................................................4 DEFINITIONS ....................................................................................................4 CONTROL CONNECTION PROTOCOL............................................................5 Messages from the server ..................................................................................5 Messages from the client ...................................................................................6 Communication scenario as seen from the client ...............................................7 VIDEO DISTRIBUTION PROTOCOL.................................................................7 VIDEO TYPES ...................................................................................................8

The use and/or disclosure, etc. of the contents of this document (or any part thereof) is subject to the restrictions referenced on the front page.
TITLE DOCUMENT NO. REV PAGE

SCANTER LAN Video Protocol

304124-SI

3 OF 8

INTRODUCTION
This document describes how to receive video from a VDT through a local area network. The protocol uses TCP/IP for its control connection and UDP for distributing video. As Terma A/S aims to improve its products continuously, we consequently reserve the rights to revise product characteristics without notice.

1.1

Scope
The scope of the protocol is the transmission of network video to a number of clients. The following control connection interfaces are defined: Interface Name SCANTER 4xxx Ch. A or SCANTER 2001 normal video SCANTER 4xxx Ch. A MTI video SCANTER 4xxx Ch. B normal video SCANTER 4xxx Ch. B MTI video Control Connection TCP Port 1500 1501 1502 1503

REFERENCED DOCUMENTATION
None

INTERFACE PROTOCOL REVISIONS

This document describes the following revisions of the protocol interfaces: Interface name Video Interface Protocol revision 2.0

The protocol revision is divided into two version numbers: major.minor. The major revision is increased when backward compatibility is broken. The minor revision is increased when functionality is added to the protocol, but backward compatibility is kept.

DEFINITIONS
VDT TCP IP ASCII UDP Video Distribution and Tracking Transmission Control Protocol Internet Protocol American Standard Code for Information Interchange User Datagram Protocol

The use and/or disclosure, etc. of the contents of this document (or any part thereof) is subject to the restrictions referenced on the front page.
TITLE DOCUMENT NO. REV PAGE

SCANTER LAN Video Protocol

304124-SI

4 OF 8

LAN Sweep Scan uint32 uint8

Local Area Network The radar return of one transmitted pulse as a function of range A collection of sweeps representing an entire revolution of the antenna Unsigned 32-bit integer Unsigned 8-bit integer

CONTROL CONNECTION PROTOCOL

In order for a client to receive video it must make a control connection, which is a TCP/IP connection where data is exchanged in an ASCII based protocol. The following two sections describe the messages that may be exchanged in this protocol. Notice that if the control connection is closed, the server will stop transmitting the corresponding video stream.

5.1

Messages from the server

Messages are transmitted from the server as a line of data which is always terminated by a carriage return (ASCII value 13dec) immediately followed by a line feed (ASCII value 10dec). This section explains the different messages that can be transmitted from the server. VERSION X.X A B C Upon connection the server sends this message. X.X is the protocol understood by the server, where X can be any integer. Refer to chapter 3 to see which protocol version corresponds to the version of this protocol document. A is the number of cells in a complete sweep B is the number of sweeps in a full scan C is the sector size The current video server implementation supports the following combination of A, B and C: A #cells/sweep 1. 4096 B #sweeps/full scan 4096 C Sector size 32

Number of sectors = B/C 128

VIDEOSOURCE <multicast IP address> <UDP port number> Response to a REQUEST_VIDEO_MULTI. This message informs the client about the multicast IP address and UDP port number where requested video can be received. For example the data could be: VIDEOSOURCE 235.17.100.120 5000
The use and/or disclosure, etc. of the contents of this document (or any part thereof) is subject to the restrictions referenced on the front page.
TITLE DOCUMENT NO. REV PAGE

SCANTER LAN Video Protocol

304124-SI

5 OF 8

Notice that the multicast IP address of choice is subject to off-line configuration of the video server. This implies that for a particular control connection, the video server is capable of transmitting only one video multicast stream at a time. RANGE X Information about the current instrumented range given in metres. This will be received whenever the instrumented range changes and upon requesting a new type of video. Should a client need the range cell size, it can be calculated by taking the range and dividing by the number of cells in a complete sweep. OK Received as response to a successful REQUEST_VIDEO_UDP BAD_COMMAND Sent by the server if a command was not understood. PING Sent periodically by the server to check whether the control connection is still open. Client cannot answer to this message. PONG Servers response to a clients PING.

5.2

Messages from the client

Messages are transmitted from the client as a line of data which is terminated by any one of a line feed (ASCII value 10dec), a carriage return (ASCII value 13dec), or a carriage return immediately followed by a line feed. This section explains the different messages that may be transmitted to the server. REQUEST_VIDEO_MULTI X Sent by a client when it wishes to subscribe to a UDP multicast video stream. X is an integer indicating the video type that should be subscribed to. The server will respond with a VIDEOSOURCE to inform about the multicast address. Section 7 describes available video types that can be subscribed to. REQUEST_VIDEO_UDP X Y Sent by a client to request unicast UDP based video. X is the video type to subscribe to and Y is the UDP port number where the client is listening for incoming video data.

The use and/or disclosure, etc. of the contents of this document (or any part thereof) is subject to the restrictions referenced on the front page.
TITLE DOCUMENT NO. REV PAGE

SCANTER LAN Video Protocol

304124-SI

6 OF 8

Section 7 describes available video types that can be subscribed to. PING Optional frame that may be sent to keep the connection alive. The server responds with a PONG.

5.3

Communication scenario as seen from the client

1. Make a socket connection to the server. 2. Wait for the VERSION message and verify that revisions match. 3. As an example, transmit REQUEST_VIDEO_UDP 2 10042 in order to receive type 2 (see section 7) unicast video on port 10042. Video will be sent to the IP address that initiated the control connection. 4. Transmit PING at regular intervals if it is required by the installation (for example if the link will be dropped by a router, firewall, etc.)

VIDEO DISTRIBUTION PROTOCOL

Video packets are sent as UDP messages having the following structure: Total payload data length uint32 Payload fragment data length uint32 Sector number uint32 Payload fragment number uint32 Payload fragment data uint8 ...

Total payload data length: Total number of payload data bytes for the sector. If the payload is fragmented across multiple video packets, this number is repeated in the header of each fragment. Payload fragment data length: Length of the payload data fragment contained within the video packet. Sector data is fragmented into several video packets if the length of the video packet exceeds 64000 bytes. Therefore, at the client side, received UDP video packets will never exceed a size of 64000 bytes. Sector number: The sector contained in this packet. Sectors are numbered: [0...number of sectors1] Payload fragment number: This contains the fragment number. Fragment numbers start at zero. Payload fragment data: A fragment or all of the video data for the sector. The receiving client must compare the payload fragment data length to the total payload data length to know whether all data for the sector has been received.
The use and/or disclosure, etc. of the contents of this document (or any part thereof) is subject to the restrictions referenced on the front page.
TITLE DOCUMENT NO. REV PAGE

SCANTER LAN Video Protocol

304124-SI

7 OF 8

Notice that the packets do not contain information about what video type they contain as this can be deduced from the subscriptions actually made in section 5.2. Delivery of UDP messages is inherently unreliable and subject to being out-of-order. Therefore, at any time, a video packet might not reach the receiving client. If the video is transmitted as UDP multicast, some clients might properly receive a certain video packet while others might not. It is furthermore the responsibility of the receiving client to decide how to handle video packets arriving out-of-order. All multi-byte values are sent in network byte order as illustrated in the following figure:
high-order byte low-order byte

addr A

addr A+1

VIDEO TYPES
At the moment, one compression scheme is defined. The following table describes the different video types.

Number Short name 2 9 Zlib 8 bit Uncompressed 8 bit

Description Compresses the sweeps in a sector using the Zlib library. Uncompressed video.

The use and/or disclosure, etc. of the contents of this document (or any part thereof) is subject to the restrictions referenced on the front page.
TITLE DOCUMENT NO. REV PAGE

SCANTER LAN Video Protocol

304124-SI

8 OF 8