**TGF Radar Rack Overview**

**and**

**Interface Control Document**

Prepared for:

Dan Warburton

ACB-860

Simulation Group (ACB-860)

Real & Virtual Division (ACB-800)

Federal Aviation Administration

William J. Hughes Technical Center

Atlantic City, NJ 08405

Prepared by:

Alicia A. Rothman

Under:

Raytheon Service Company

**August 22, 1997**

TABLE OF CONTENTS

[1. INTRODUCTION 1](#__RefHeading___Toc53449515)

[1.1 PURPOSE 1](#purpose)

[1.2 ORGANIZATION 1](#organization)

[2. OVERVIEW 1](#overview)

[2.1 RADAR BOX TASKING MODEL 3](#radar-box-tasking-model)

[2.1.1 Radar Box Monitor 3](#radar-box-monitor)

[2.1.2 Device Servers 3](#device-servers)

[2.1.2.1 Radar Transmitter Device 3](#radar-transmitter-device)

[2.1.2.2 Radar Receiver Device 3](#radar-receiver-device)

[2.1.2.3 Interfacility Device 4](#interfacility-device)

[2.1.3 TGF Server 4](#tgf-server)

[2.2 ECO TO TGF INTERFACE 4](#eco-to-tgf-interface)

[2.3 RADAR BOX HARDWARE 5](#radar-box-hardware)

[3. RADAR BOX MONITOR INTERFACE PROTOCOL
7](#radar-box-monitor-interface-protocol)

[3.1 RESOURCE AVAILABILITY REQUEST 7](#resource-availability-request)

[3.2 RESOURCE AVAILABILITY RESPONSE 8](#resource-availability-response)

[3.2.1 Host Name 8](#host-name)

[3.2.2 Devices 8](#devices)

[3.2.3 Device List 8](#device-list)

[3.2.3.1 Device Name 9](#device-name)

[3.2.3.2 Device Type 9](#device-type)

[3.2.3.3 Owner 10](#owner)

[3.2.3.4 Card Identifier 10](#card-identifier)

[3.2.3.5 Network Port 10](#network-port)

[3.2.3.6 Description 10](#description)

[4. DEVICE ACCESS SERVER PROTOCOL 11](#device-access-server-protocol)

[4.1 DEVICE OPEN 11](#device-open)

[4.1.1 Device Name 12](#device-name-1)

[4.2 DEVICE OPEN REPLY 12](#device-open-reply)

[4.2.1 Device Name 13](#device-name-2)

[4.2.2 Status 13](#status)

[4.2.3 Error Message 13](#error-message)

[4.3 DEVICE CLOSE 13](#device-close)

[4.3.1 Device Name 14](#device-name-3)

[4.4 DEVICE DATA 14](#device-data)

[4.4.1 Radar Device Data Packets 14](#radar-device-data-packets)

[4.4.1.1 Channel 15](#channel)

[4.4.1.2 Type 15](#type)

[4.4.1.3 Flags 16](#flags)

[4.4.1.4 Time 16](#time)

[4.4.1.5 Size 16](#size)

[4.4.1.6 Data 16](#data)

[4.4.1.6.1 Aircraft 16](#aircraft)

[4.4.1.6.2 Sector Marks 17](#sector-marks)

[4.4.1.6.3 Real Time Quality Control (RTQC)
17](#real-time-quality-control-rtqc)

[4.4.1.6.4 Weather 17](#weather)

[4.4.2 IF Device Data Packets 17](#if-device-data-packets)

[4.4.2.1 Message Type 18](#message-type)

[4.4.2.2 Flags 18](#flags-1)

[4.4.2.3 Size 18](#size-1)

[4.4.2.4 Time 18](#time-1)

[4.4.2.5 Data 18](#data-1)

[4.5 DEVICE I/O CONTROL (IOCTL) 19](#device-io-control-ioctl)

[4.5.1 Radar IOCTL Messages 19](#radar-ioctl-messages)

[4.5.1.1 Start 19](#start)

[4.5.1.2 Invert 19](#invert)

[4.5.1.3 Physical Interface 20](#physical-interface)

[4.5.1.4 Receiver Clock 20](#receiver-clock)

[4.5.1.5 Setowner 20](#setowner)

[4.5.2 Interfacility (IF) IOCTL Messages
20](#interfacility-if-ioctl-messages)

[4.5.2.1 Start 20](#start-1)

[4.5.2.2 Receiver Clock 20](#receiver-clock-1)

[4.5.2.3 Transmitter Clock 20](#transmitter-clock)

[4.5.2.4 Setowner 20](#setowner-1)

[5. TARGET GENERATOR FACILITY SERVER PROTOCOL
22](#target-generator-facility-server-protocol)

[5.1 SPECIFIC RADAR PACKETS 23](#specific-radar-packets)

[5.1.1 TGF Open Request 23](#tgf-open-request)

[5.1.1.1 Radar Name 23](#radar-name)

[5.1.1.1.2 Device Name 24](#device-name-4)

[5.1.1.3 Radar Type 24](#radar-type)

[5.1.1.4 Scan Rate 24](#scan-rate)

[5.1.2 TGF Open Reply 24](#tgf-open-reply)

[5.1.2.1 Status 25](#status-1)

[5.1.2.2 Radar Name 25](#radar-name-1)

[5.1.2.3 Error Message 25](#error-message-1)

[5.1.3 TGF Data 25](#tgf-data)

[5.1.3.1 Radar Name 26](#radar-name-2)

[5.1.3.2 Target Reports 26](#target-reports)

[5.1.3.3 Messages 26](#messages)

[5.1.3.3.1 Message Type 26](#message-type-1)

[5.1.3.3.2Time 26](#time-2)

[5.1.4 TGF Close 27](#tgf-close)

[5.1.4.1 Device Name 27](#device-name-5)

[5.2 GLOBAL PACKETS 28](#global-packets)

[5.2.1 TGF Start 28](#tgf-start)

[5.2.1.1 Time 28](#time-3)

[5.2.2 TGF Stop 28](#tgf-stop)

[5.2.3 TGF Pause 29](#tgf-pause)

[5.2.4 TGF End-of-Epoch 29](#tgf-end-of-epoch)

[5.2.4.1 Time 29](#time-4)

[APPENDIX 31](#appendix)

[APPENDIX A -- Acronym List 31](#appendix-a-acronym-list)

[APPENDIX B -- RISCom/8Si Base Address, IRQ, and IO Port Settings
32](#appendix-b-riscom8si-base-address-irq-and-io-port-settings)

[APPENDIX C -- Specific RBX Components
33](#appendix-c-specific-rbx-components)

[APPENDIX D -- RBX/Bytex Cable Pinouts
33](#appendix-d-rbxbytex-cable-pinouts)

[APPENDIX E -- UDP/TCP Port Assignments
34](#appendix-e-udptcp-port-assignments)

[APPENDIX F -- CD2 Format 34](#appendix-f-cd2-format)

[APPENDIX G -- Header File Summaries
34](#appendix-g-header-file-summaries)

LIST OF ILLUSTRATIONS

[Figure 2-1 General Overview 1](#__RefHeading___Toc53283155)

[Figure 2-2 TGF to RBX Architectural Interface
5](#__RefHeading___Toc53283156)

[Figure 2-3 Radar Rack 6](#__RefHeading___Toc53283157)

[Figure 4-1 Radar Receiver Communication
21](#__RefHeading___Toc53283158)

[Figure 5-1 Radar Transmitter Communication
30](#__RefHeading___Toc53283159)

**LIST OF TABLES**

Table 2-1 RBX Interface Packet Types [2](#__RefHeading___Toc53286221)

Table 3-1 RBX Monitor Packet Type Enumeration
[7](#__RefHeading___Toc53286224)

Table 3-2 Resource Availability Request Packet
[7](#__RefHeading___Toc53286225)

Table 3-3 RBX Resource Availability Response Packet
[8](#__RefHeading___Toc53286226)

Table 3-4 Device List Information [9](#tab34)

Table 3-5 Device Types [9](#__RefHeading___Toc53286228)

Table 4-1 Device Access Server Packet Type Enumeration
[11](#__RefHeading___Toc53286229)

Table 4-2 Device Open Packet [12](#__RefHeading___Toc53286230)

Table 4-3 Device Open Reply Packet [12](#__RefHeading___Toc53286231)

Table 4-4 Device Close Packet [13](#__RefHeading___Toc53286232)

Table 4-5 Radar Device Data Packet [15](#__RefHeading___Toc53286233)

Table 4-6 IF Device Data Packet [17](#__RefHeading___Toc53286234)

Table 4-7 Device IOCTL Enumeration [19](#__RefHeading___Toc53286235)

Table 5-1 TGF Server Packet Type Enumeration
[22](#__RefHeading___Toc53286237)

Table 5-2 TGF Open Request Packet [23](#__RefHeading___Toc53286238)

Table 5-3 TGF Open Reply Packet [24](#__RefHeading___Toc53286239)

Table 5-4 TGF Data Packet [25](#__RefHeading___Toc53286240)

Table 5-5 TGF Message Header [26](#__RefHeading___Toc53286241)

Table 5-6 TGF Close Packet [27](#__RefHeading___Toc53286242)

Table 5-7 TGF Start Packet [28](#__RefHeading___Toc53286243)

Table 5-8 TGF Stop Packet [28](#tab58)

Table 5-9 TGF Pause Packet [29](#__RefHeading___Toc53286245)

Table 5-10 TGF End-of-Epoch Packet [29](#__RefHeading___Toc53286246)

# 1. INTRODUCTION

The Target Generation Facility at William J. Hughes Technical Center was
developed to provide a simulation test bed for performing Operation Test
and Evaluation (OT&E) on new equipment and functions, to refine both
current and proposed Air Traffic Control (ATC) systems and concepts, and
to verify operational readiness prior to being deployed into the
National Airspace System. It provides high fidelity, real-time
capabilities necessary to support both OT&E and Research and Development
(R&D). Radar Boxes are being used to simulate radar necessary for
testing.

## 1.1 PURPOSE

The TGF Radar Rack Overview and Interface Control Document (ICD) defines
the interface between the Target Generator Facility Chassis and radar
boxes. This ICD describes the communication interface between these
systems.

## 1.2 ORGANIZATION

The TGF at the Federal Aviation Administration William J. Hughes
Technical Center (FAA Technical Center) is managed by the System
Simulation Support Branch, ACT-510, of the Aviation Simulation and Human
Factors Division, ACT-500.

# 2. OVERVIEW

The Radar Box (RBX) computers provide the main interface between the
Technical Center ATC Laboratories and the TGF. The RBX computers are
capable of transmitting radar, receiving radar and performing
interfacility (IF) communication. They are used during simulations to
provide radar and IF communication between the TGF and the ATC
Laboratories. Figure 2-1 shows a general overview of the interface to
the RBX.

 

![](media/image1.wmf){width="5.996527777777778in"
height="1.0854166666666667in"}

[]{#__RefHeading___Toc53283155 .anchor}Figure 2-1 General Overview

 

The remainder of this section will discuss the RBX tasking model, the
Exercise Control Operator (ECO) to TGF Interface, the RBX hardware and
the RBX software.

 

The remainder of the document will discuss the protocols of the three
interfaces to the RBX.

 

-   RBX Monitor Interface

-   Device Access Server

-   TGF Server

The RBX monitor interface allows the status of available devices to be
queried. The device access server provides the capability of working
with the devices on a low level. The TGF server handles all radar data
transmission. Table 2-1 provides a list of the packet types that are
passed over the network by each of these interfaces.

 

[]{#__RefHeading___Toc53286221 .anchor}Table 2-1 RBX Interface Packet
Types

RBX Monitor Device Access Server TGF Server

Resource Availability Device Open TGF Open

Request Device Open Reply TGF Open

Reply

Resource Availability Device Close TGF Data

Response Device Data TGF Close

Device IO Control (IOCTL) TGF Start

TGF Stop

TGF Pause

TGF End of Epoch

## 2.1 RADAR BOX TASKING MODEL

There are several tasks that run in conjunction with the radar boxes.
These processes are the radar box monitor (RBXM), the Device servers,
and the TGF server. See Appendix E for the UDP/TCP Port Assignments of
the processes that run on the RBX computers. The following is a
description of each of these tasks.

### 2.1.1 Radar Box Monitor

The Radar Box Monitor (RBXM) keeps a record of the status of each device
on the RBX computers. When a machine, usually the ECO, requests
information regarding the status of the devices, the RBXM gathers the
information and sends a reply to the requestor. The RBXM is listening on
port 6000 for requests. See section 3 for a complete description of the
RBXM interface protocol.

### 2.1.2 Device Servers

The Device Servers make the RBX devices available over the network. The
following are the three types of device servers that run on the RBX.

-   Radar Transmitter Device (PRDRTXD)

-   Radar Receiver Device (PRDRRXD)

-   Interfacility Device (PIFD)

Section 4 provides a complete description of the device access server
protocol. The following is a description of these device servers.

#### 2.1.2.1 Radar Transmitter Device

The Pseudo Radar Transmitter Device (PRDRTXD) communicates directly with
the radar transmitter devices on the RBX computers and allows other
processes to send radar data out of the RBX. A PRDRTXD is invoked by the
inetd daemon whenever a request to open a transmitter device is
received. The PRDRTXD listens on port 6001.

#### 2.1.2.2 Radar Receiver Device

The Pseudo Radar Receiver Device (PRDRRXD) communicates directly with
the radar receiver devices on the RBX computers and allows other
processes to receive radar data from any radar source connected to the
Bytex including the TGF itself. A PRDRRXD is invoked by the inetd daemon
whenever a request to open a receiver device is received. The PRDRRXD
listens on port 8000.

#### 2.1.2.3 Interfacility Device

The Pseudo Interfacility Device (PIFD) communicates directly with the IF
devices on the RBX computers and allows other processes to conduct IF
communications with other entities connected to the Bytex. A PIFD is
invoked by the inetd daemon whenever a request to open an IF device is
received. The PIFD listens on port 7000.

### 2.1.3 TGF Server

The TGF Server is responsible for sending data to the RBX computers. It
communicates with the Chassis, the PRDRTXD, the PRDRRXD, and the PIFD.
The TGF Server passes information between the Chassis and the
appropriate device. The TGF Server listens on port 9050 + the Chassis
number. Section 5 provides a complete description of the TGF server
protocol.

## 2.2 ECO TO TGF INTERFACE

Initial communication with the RBX computers takes place using an
Exercise Control Workstation (ECW). The operator of the ECW, the ECO, is
responsible for configuring and starting a simulation. The ECO sends a
request to the RBXM to determine which devices are available. The RBXM
responds to the request with information on the status of each resource
that the RBX computers possess. The ECO then chooses available radar and
the TGF Chassis is notified of these choices.

 

The Core Target Generator (CTG) sends an open request from the Chassis
to the RBX TGF Server for each radar selected. The RBX reserves the
requested radar so that no other resources can utilize it. Throughout
the simulation, the Target Generator Executive (TGE) sends start, pause,
and close messages from the Chassis to the RBX. While the simulation is
running, the CTG sends radar messages to the RBX continuously. The TGE
is responsible for sending an end-of-epoch message to the RBX once every
second.

 

Figure 2-2 presents an architectural overview of the TGF to RBX
interface.

![](media/image2.wmf){width="5.999305555555556in"
height="5.081944444444445in"}

[]{#__RefHeading___Toc53283156 .anchor}Figure 2-2 TGF to RBX
Architectural Interface

### 2.3 RADAR BOX HARDWARE

Each RBX is a 120 Megahertz Pentium computer running the Linux operating
system (version 2.0). These rack mounted PCs contain 2 Gigabytes of disk
space connected to a high performance PCI SCSI controller as well as 32
Megabytes of RAM. A 3Com 10/100 ethernet network adapter running at 10
mbs provides network connectivity. SDL Communications' RISCom/8Si
multi-port serial cards provide radar and interfacility functionality.
See Appendix B for the base address, IRQ, and IO port settings for the
RISCom/8Si serial boards. See Appendix C for more information on the
specific components of the RBX computers.

 

The radar rack consists of multiple RBX computers mounted in a 19\" rack
cabinet with a monitor, keyboard, and mouse. A Raritan Master Console
switch is used to connect these peripherals to the multiple RBX
computers. Breakout boxes for the RISCom/8Si serial boards are mounted
in the rear of the radar rack to facilitate connectivity with the Bytex
switch. Each breakout box consists of 8 DB-25 Male connectors; one for
each serial port on a single RISCom/8Si. Custom cables are used to
connect the radar rack to the Bytex. See Appendix D for the radar rack /
Bytex cable pinouts. Network connectivity is provided by an SMC Ether EZ
mini-hub.

 

Communication between the main TGF system and the RBX computers is
provided by a 10 BaseT network. Category 5 cabling is used. The ethernet
interface on the chassis is either provided on board the Heurikon
Nitro60 Single Board Computers (SBC), or on board the Heurikon V30XE
SBCs. The V30XE is used in the older TGF systems and the Nitro60 is used
in the newer systems.

 

Figure 2-3 shows the Radar Rack containing three Radar Boxes.

![](media/image3.wmf){width="2.9381944444444446in"
height="3.4722222222222223in"}

[]{#__RefHeading___Toc53283157 .anchor}Figure 2-3 Radar Rack

# 3. RADAR BOX MONITOR INTERFACE PROTOCOL

The RBX monitor network protocol contains the configuration information
for the devices that are built into the RBX. The following paragraphs
describe the RBX monitor protocol, which defines the two packet types
that can go over the network. Table 3-1 shows the enumeration of the
packet types for the RBX monitor protocol. See Figure 4-1 and Figure 5-1
for the communication between the RBX monitor and a client.

 

[]{#__RefHeading___Toc53286224 .anchor}Table 3-1 RBX Monitor Packet Type
Enumeration

  ------------------------------- ---------------------- -----------------
  **Packet Type**                 **Abbreviation**       **Enumeration**

  Resource Availability Request   INFO_REQ               0

  Resource Availability Response  INFO_RESP              1
  ------------------------------- ---------------------- -----------------

## 

## 3.1 RESOURCE AVAILABILITY REQUEST

A Resource Availability Request packet asks the RBX what devices it
possesses and what the status is of each of these devices. On startup,
the ECO sends a Resource Availability Request packet by UDP broadcast.
Every RBX on the network sees the request and will issue a response. A
request requires no additional information. Table 3-2 presents the
format of the information included in a Resource Availability Request
packet.

[]{#__RefHeading___Toc53286225 .anchor}Table 3-2 Resource Availability
Request Packet

+-------------------+---------+----------------------------+-----------+
| **Field**         | **L     | **Format**                 | **Value** |
|                   | ength** |                            |           |
|                   |         |                            |           |
|                   | **(     |                            |           |
|                   | Byte)** |                            |           |
+-------------------+---------+----------------------------+-----------+
| Packet Type       | 4       | Enumeration                | INFO_REQ  |
+-------------------+---------+----------------------------+-----------+

##  3.2 RESOURCE AVAILABILITY RESPONSE

A Resource Availability Response packet includes all the information
about each of the devices on a particular RBX. The response packet is
sent UDP unicast back to the requestor. This allows the requestor (ECO)
to distinguish between those devices that are available and those that
are already in use. A response will include the name, devices, and a
device list. Table 3-3 presents the format of the information included
in a Resource Availability Response packet

[]{#__RefHeading___Toc53286226 .anchor}Table 3-3 RBX Resource
Availability Response Packet

+-------------------+---------+----------------------------+-----------+
| **Field**         | **L     | **Format**                 | **Value** |
|                   | ength** |                            |           |
|                   |         |                            |           |
|                   | **(     |                            |           |
|                   | Byte)** |                            |           |
+-------------------+---------+----------------------------+-----------+
| Packet Type       | 4       | Enumeration                | INFO_RESP |
+-------------------+---------+----------------------------+-----------+
| Host Name         | 40      | ASCII String               |           |
+-------------------+---------+----------------------------+-----------+
| Devices           | 4       | Integer                    |           |
+-------------------+---------+----------------------------+-----------+
| Device List       | 48      | ASCII String               |           |
+-------------------+---------+----------------------------+-----------+

### 

### 3.2.1 Host Name

Host Name is a 40-byte ASCII character field used to identify the host
that is responding.

### 3.2.2 Devices

Devices is an integer field that indicates the number of device lists
that will follow in the packet.

### 3.2.3 Device List

The Device List contains the actual information about each device that
an RBX computer possesses. The list will include the device name, device
type, owner, card identifier, network port and a description. Table 3-4
presents the format of the information included in the Device List.

[]{#tab34 .anchor}

Table 3-4 Device List Information

+-------------------+---------+----------------+----------------------+
| **Field**         | **L     | **Format**     | **Value**            |
|                   | ength** |                |                      |
|                   |         |                |                      |
|                   | **(     |                |                      |
|                   | Byte)** |                |                      |
+-------------------+---------+----------------+----------------------+
| Device Name       | 12      | ASCII String   |                      |
+-------------------+---------+----------------+----------------------+
| Device Type       | 4       | Enumeration    | IF, RDR_TX, or       |
|                   |         |                | RDR_RX               |
+-------------------+---------+----------------+----------------------+
| Owner             | 4       | Integer        |                      |
+-------------------+---------+----------------+----------------------+
| Card Identifier   | 4       | Integer        |                      |
+-------------------+---------+----------------+----------------------+
| Network Port      | 4       | Integer        |                      |
+-------------------+---------+----------------+----------------------+
| Description       | 20      | ASCII String   |                      |
+-------------------+---------+----------------+----------------------+

#### 

#### 3.2.3.1 Device Name

The Device Name consists of a 12-byte ASCII character field used to
uniquely identify each device.

#### 3.2.3.2 Device Type

The Device Type is an enumerated integer field used to identify what the
device can simulate. It will either indicate a radar transmitter, a
radar receiver, or an IF connection. Table 3-5 presents the enumeration
of the types of devices.

 

[]{#__RefHeading___Toc53286228 .anchor}Table 3-5 Device Types

  ------------------------------- ------------------ --------------------
  **Device Type**                 **Abbreviation**   **Enumeration**

  Interfacility                   IF                 0

  Radar Transmitter               RDR_TX             1

  Radar Receiver                  RDR_RX             2
  ------------------------------- ------------------ --------------------

####  3.2.3.3 Owner

The Owner is an integer field that indicates if a device is being used
or if it is available. A zero indicates that it is available and any
other integer indicates it is in use. If a device is being used, the
number identifies the owner. A relatively low number, between 1 and 100,
probably indicates that a Chassis is using the device and that number
identifies the Chassis. A large number indicates that a program is using
the device and that number identifies the process ID of the program.

#### 3.2.3.4 Card Identifier

Each RBX can contain up to three SI8 cards. Each SI8 card may have two
radar transmitter devices, two radar receiver devices, or eight IF
devices. The devices on each card must all be the same. Each card has a
different IO Port, an arbitrary value, which can be used to identify the
cards. See Appendix B for the IO Port settings of the physical cards.

#### 3.2.3.5 Network Port

The Network Port field identifies which port is used to access a device
on the network. It provides the interface to the local area network.
This field is currently unused.

#### 3.2.3.6 Description

The Description field is a logical name for the machine and the device.
It identifies a particular device and which machine it is on. For
example, rbx1-rx0 refers to radar receiver 0 on radar box 1. By
convention, the Description also identifies on which ports the data will
be located on the Bytex.

# 4. DEVICE ACCESS SERVER PROTOCOL

The RBX Device Access Servers are the services available on the RBX that
anyone can access through the network. The three different types of
devices that are accessible through the RBX are radar transmitters,
radar receivers and IF. Radar transmitters and receivers can only send
radar or receive radar, while IF can communicate in both directions. A
radar transmitter receives radar from the Chassis and sends it out like
actual radar. A radar receiver receives radar from the Bytex and puts
the information into a readable form so that the radar can be monitored.
An IF device can transmit and receive radar at the same time. The
following is a description of the Device Access protocol, which defines
the operations that can be performed on the three devices. These
operations include device open, device open reply, device close, device
data, and device IO control (IOCTL). All devices are accessed using UDP
unicast packets. The first piece of information in each of these packets
is an enumerated integer field that identifies the type of packet that
is being sent. Table 4-1 shows the enumeration of the packet types for
the device access server protocol. See Figure 4-1 for the communication
between the radar receiver and a client.

 

[]{#__RefHeading___Toc53286229 .anchor}Table 4-1 Device Access Server
Packet Type Enumeration

  ------------------------------ --------------------- -------------------
  **Packet Type**                **Abbreviation**      **Enumeration**

  Device Open                    DEV_OPEN              0

  Device Open Reply              DEV_OPEN_REPLY        1

  Device Close                   DEV_CLOSE             2

  Device Data                    DEV_DATA              3

  Device I/O CONTROL             DEV_IOCTL             4
  ------------------------------ --------------------- -------------------

## 

## 4.1 DEVICE OPEN

A device is opened after the server receives a packet requesting the
device. A device open can be issued by anyone who wishes to open a
connection to an RBX and reserve a device. This is required prior to the
start of data packet transmission. The packet includes the name of the
device to be opened. Table 4-2 presents the format of the information
included in the Device Open packet.

[]{#__RefHeading___Toc53286230 .anchor}Table 4-2 Device Open Packet

+-------------------+------------+----------------------+------------+
| **Field**         | **Length** | **Format**           | **Value**  |
|                   |            |                      |            |
|                   | **(Byte)** |                      |            |
+-------------------+------------+----------------------+------------+
| Packet Type       | 4          | Enumeration          | DEV_OPEN   |
+-------------------+------------+----------------------+------------+
| Device Name       | 12         | ASCII String         |            |
+-------------------+------------+----------------------+------------+

### 

### 4.1.1 Device Name

Device Name is a 12-byte ASCII character field that is used to identify
the name of the device to be opened. The Device Name will be in one of
the following formats:

-   rdrtxN

-   rdrrxN

-   ifN

The 'N' represents an integer between zero and the number of devices
that exist.

## 4.2 DEVICE OPEN REPLY

After the RBX has attempted to open a device that has been requested, it
sends a reply back to the machine that sent the open request with the
results of the attempt to open the device. The packet includes the name
of the device, the status of the device and possibly an error message.
Table 4-3 presents the format of the information included in the Device
Open Reply packet.

[]{#__RefHeading___Toc53286231 .anchor}Table 4-3 Device Open Reply
Packet

+-------------------+---------+-------------------+------------------+
| **Field**         | **L     | **Format**        | **Value**        |
|                   | ength** |                   |                  |
|                   |         |                   |                  |
|                   | **(     |                   |                  |
|                   | Byte)** |                   |                  |
+-------------------+---------+-------------------+------------------+
| Packet Type       | 4       | Enumeration       | DEV_OPEN_REPLY   |
+-------------------+---------+-------------------+------------------+
| Device Name       | 12      | ASCII String      |                  |
+-------------------+---------+-------------------+------------------+
| Status            | 4       | Integer           |                  |
+-------------------+---------+-------------------+------------------+
| Error Message     | Varied  | ASCII String      |                  |
+-------------------+---------+-------------------+------------------+

### 4.2.1 Device Name

The Device Name is a 12-byte ASCII character field used to identify the
device that the RBX attempted to open. The Device Name will be in one of
the following formats:

-   rdrtxN

-   rdrrxN

-   ifN

The 'N' represents an integer between zero and the number of devices
that exist.

### 4.2.2 Status

The Status is an integer field that gives the results of the attempt to
open the device. The status of the device will be zero if the RBX was
able to open it. If the device could not be opened the status will be
the error number returned by the operating system.

### 4.2.3 Error Message

An Error Message is included in the packet to explain why a device could
not be opened. It is a null terminated ASCII string of variable length.
The message is the standard error string for the particular status that
is given.

## 4.3 DEVICE CLOSE

A device should be closed when the device is no longer required, i.e.,
at the end of a simulation. The packet contains a field to identify the
name of the device to be closed. Table 4-4 presents the format of the
information included in the Device Close packet.

 

[]{#__RefHeading___Toc53286232 .anchor}Table 4-4 Device Close Packet

+-------------------+------------+----------------------+------------+
| **Field**         | **Length** | **Format**           | **Value**  |
|                   |            |                      |            |
|                   | **(Byte)** |                      | ** **      |
+-------------------+------------+----------------------+------------+
| Packet Type       | 4          | Enumeration          | DEV_CLOSE  |
+-------------------+------------+----------------------+------------+
| Device Name       | 12         | ASCII String         |            |
+-------------------+------------+----------------------+------------+

###  

### 4.3.1 Device Name

Device Name is a 12-byte ASCII character field used to identify the name
of the device to be closed. The Device Name will be in one of the
following formats:

-   rdrtxN

-   rdrrxN

-   ifN

The 'N' represents an integer between zero and the number of devices
that exist.

## 4.4 DEVICE DATA

After a start has been issued, data packets are passed to the RBX from
the Chassis. The data that is passed to the Radar Servers is different
than the data that is passed to the IF Server.

### 4.4.1 Radar Device Data Packets

Radar receiver devices provide radar data from sources connected to the
Bytex to any client that connects to it. A device Open / Device Open
Reply transaction must successfully take place before Device Data
packets can be received. The radar data type defaults to long range
radar; short range must be specified if it is desired. A Start must be
issued in order to receive radar data packets.

 

When the device is a radar transmitter, a similar process occurs. A
Device Open must be sent and then a Device Open Reply should be
received. When a start is issued, the Chassis begins sending data
packets to the RBX, which reformats the data and transmits it as actual
radar to the Bytex.

 

Table 4-5 presents the format of the data that can be both sent and
received in the Device Data packets to the Radar Servers. All fields
prior to the Data field are considered the header of the Data Packet.

 

[]{#__RefHeading___Toc53286233 .anchor}Table 4-5 Radar Device Data
Packet

+-------------------+------------+-----------------+-----------------+
| **Field**         | **Length** | **Format**      | **Value**       |
|                   |            |                 |                 |
|                   | **(Byte)** |                 |                 |
+-------------------+------------+-----------------+-----------------+
| Channel           | 1          | Integer         | '0', '1', '2',  |
|                   |            |                 | '3'             |
+-------------------+------------+-----------------+-----------------+
| Type              | 4          | Enumeration     |                 |
+-------------------+------------+-----------------+-----------------+
| Flags             | 1          | Bit Field       |                 |
+-------------------+------------+-----------------+-----------------+
| Time              | 4          | Integer         | 1/100 seconds   |
+-------------------+------------+-----------------+-----------------+
| Size              | 1          | Integer         |                 |
+-------------------+------------+-----------------+-----------------+
| Data              | 64         | Binary          |                 |
+-------------------+------------+-----------------+-----------------+

#### 

#### 4.4.1.1 Channel

The Channel field is a 1 byte integer that indicates, for a radar
transmitter, on which radar channel to transmit data. There are four
channels on each RBX card. A zero in this field indicates that any
channel may be used. For a radar receiver, this field indicates on which
channel the data was received.

#### 4.4.1.2 Type

The Type is 1 byte that identifies the type of the message. The
following is a list of the different types of radar messages that may be
received or transmitted.

Search Strobe

Beacon Status

Beacon Reinforced Search Real Time Quality Control (RTQC)

HGT Beacon RTQC

Sector Mark (SM) ASR9 -- Terminal

Scip Control LD2 -- Enroute Weather (MAP)

#### 4.4.1.3 Flags

Flags is a bit field that is used to indicate errors. When an error
occurs a bit is set that represents a particular error. The three types
of errors that may arise are Malfunction errors, Invalid Header errors,
and Synchronization errors. Bits 0, 1, and 2 represent them,
respectively.

#### 4.4.1.4 Time

The Time is a 4 byte integer that indicates the simulation time in
hundredths of seconds.

#### 4.4.1.5 Size

The Size is 1 byte that indicates the size of the message in the Data
section. The size is given as the number of 16 bit words that are
significant and should be read from the data. Each 16 bit word contains
a 12 bit radar word pre-padded with 4 bits.

#### 4.4.1.6 Data

The Data is 32 2-byte words containing specific information for the
message depending on the type of message being received. Only the first
number of words given by Size contain valid Data. The least significant
12 bits of each two byte word contain the actual radar data. The
following is a description of the types of messages that could be
passed, including Aircraft information, Sector Marks, Real Time Quality
Control (RTQC), or Weather information. This Data is the raw radar data.
For Enroute the format will be CD2 and for terminal it will be ASR9. See
Appendix F for the CD2 format. The following are the CD2 messages
supported by TGF.

Map Search

Search RTQC Beacon

Strobe Status

##### 

##### 4.4.1.6.1 Aircraft

An Aircraft message includes the range and azimuth. The slant range
indicates the distance from the radar to the target. The azimuth is the
number of Azimuth Change Pulses (ACP) the radar has rotated through to
detect a target. The message may also include the beacon code and the
altitude of the aircraft.

##### 

##### 4.4.1.6.2 Sector Marks

A Sector Mark message indicates the number of the subsector sent for
ASR9 radars only.

##### 4.4.1.6.3 Real Time Quality Control (RTQC)

RTQC messages are used to determine if there is a problem with the
radar. A problem may be detected if there is a change in the fixed
target that the radar generates.

##### 4.4.1.6.4 Weather

A Weather message shows how dense the weather is at a particular
location.

### 4.4.2 IF Device Data Packets

The IF device is able to communicate with the TG Chassis to transmit and
receive radar. The TG Chassis, acting as the client, needs to establish
a TCP/IP socket for communication with the IF device. Once a connection
is established they can exchange data packets. The format of the data
packets is the same traveling in both directions.

 

An IF Device Data packet includes the packet type, IF message type,
error flags, size, a timestamp, and IF data. Table 4-6 presents the
format of the information sent and received in the Device Data packets
to the IF Server.

 

[]{#__RefHeading___Toc53286234 .anchor}Table 4-6 IF Device Data Packet

+-----------------+----------------+----------------+-----------------+
| **Field**       | **Length**     | **Format**     | **Value**       |
|                 |                |                |                 |
|                 | **(Byte)**     |                |                 |
+-----------------+----------------+----------------+-----------------+
| Packet Type     | 4              | Enumeration    | IF_MSG          |
+-----------------+----------------+----------------+-----------------+
| Message Type    | 1              | Enumeration    |                 |
+-----------------+----------------+----------------+-----------------+
| Flags           | 1              | Bit Field      |                 |
+-----------------+----------------+----------------+-----------------+
| Size            | 2              | Short Integer  |                 |
+-----------------+----------------+----------------+-----------------+
| Time            | 8              | Long Integer   |                 |
+-----------------+----------------+----------------+-----------------+
| Data            | 248            | EBCDIC         |                 |
+-----------------+----------------+----------------+-----------------+

#### 

#### 4.4.2.1 Message Type

The Message Type is an enumerated integer field that indicates what type
of IF message is being sent or received.

 

#### 4.4.2.2 Flags

Flags is a bit field that is used to indicate errors. When an error
occurs a bit is set that represents a particular error. The three types
of errors that may arise are parity errors, LRC errors, and no end of
message errors represented by bits 0, 1, and 3, respectively.

#### 4.4.2.3 Size

The Size field is a short integer that indicates the size of the IF
message that is valid.

#### 4.4.2.4 Time

The Time field indicates the simulation time in hundredths of seconds.

#### 4.4.2.5 Data

The Data field contains the exact data that is being exchanged between
and IF systems. The maximum size of the message is 248 bytes. The format
of the data is EBCDIC. See Appendix A of the NAS-MD-640 document for the
IF message formats.

## 4.5 DEVICE I/O CONTROL (IOCTL)

The IOCTL packet contains miscellaneous information that is used to set
up and control the devices. There are different IOCTL messages for radar
and IF communication. Table 4-7 shows the enumeration and arguments of
the IOCTL messages.

 

[]{#__RefHeading___Toc53286235 .anchor}Table 4-7 Device IOCTL
Enumeration

  ----------------- -------------- ----------------- ------------------------
  **Message Type**  **Radar/IF**   **Enumeration**   **Argument**

  Start             Radar/IF       2                 Simulation time

  Transmitter Clock IF             4                 Baud rate (0 = external
                                                     clock)

  Receiver Clock    IF             5                 Baud rate (0 = external
                                                     clock)

  Invert            Radar          6                 

  Physical          Radar          7                 0 = RS-232, 1 = RS-422
  Interface                                          

  Receiver Clock    Radar          8                 Baud rate (0 = external
                                                     clock)

  Setowner          Radar/IF       10                Chassis number
  ----------------- -------------- ----------------- ------------------------

### 

### 4.5.1 Radar IOCTL Messages

The following is a description of the different types of messages that a
Radar IOCTL packet can include.

#### 4.5.1.1 Start

The Start message sets the clock and allows data packet transmission.

#### 4.5.1.2 Invert

The Invert message changes the polarity of the data.

#### 

#### 4.5.1.3 Physical Interface

The Physical Interface message toggles the physical data between
balanced and unbalanced. Normally short range radar is balanced, RS-422,
and long range radar is unbalanced, RS-232. The TGF sends all radar
RS-232 and the Bytex handles the conversion to RS-422 for short range.

#### 4.5.1.4 Receiver Clock

The receiver message sets the baud rate of the radar receiver's clock.
The normal default is zero, which allows the radar to accept an external
clock. If the clock is set, the baud rate for the line is generated
internally.

#### 4.5.1.5 Setowner

The Setowner message is used to configure the device and report the
current owner. The default owner is the process id.

### 4.5.2 Interfacility (IF) IOCTL Messages

The following is a description of the different types of messages that
an IF IOCTL packet can include.

#### 4.5.2.1 Start

The Start message sets the clock and allows packets of data to begin
being passed.

#### 4.5.2.2 Receiver Clock

The receiver clock message sets the rate of the IF clock.

#### 4.5.2.3 Transmitter Clock

The transmitter clock message sets the rate of the IF clock.

 

#### 4.5.2.4 Setowner

The final information in the packet is called setowner and is used to
configure the device and report the current owner. The default owner is
the process id.

![](media/image4.wmf){width="5.995138888888889in"
height="6.354861111111111in"}

[]{#__RefHeading___Toc53283158 .anchor}Figure 4-1 Radar Receiver
Communication

# 5. TARGET GENERATOR FACILITY SERVER PROTOCOL

The TGF Server is a daemon process, which runs on the RBX to handle
radar transmission for the TGF Chassis. The TGF Server receives target
reply blocks from the various processes running on the TGF Chassis. The
TGF Server combines these blocks into a single time sorted message queue
for each radar. The following paragraphs describe the TGF Server
protocol, which defines the packet types that can go over the network.
The first piece of information in each packet is an enumerated integer
field that identifies the type of packet being sent. Table 5-1 shows the
enumeration of the packet types for the TGF server protocol. See Figure
5-1 for the communication between a radar transmitter, the ECO, and the
Chassis.

 

[]{#__RefHeading___Toc53286237 .anchor}Table 5-1 TGF Server Packet Type
Enumeration

  ---------------------------- -------------------------- -----------------
  **Packet Type**              **Abbreviation**           **Enumeration**

  TGF Open Request             TGF_OPEN                   0

  TGF Open Reply               TGF_OPEN_REPLY             1

  TGF Data                     TGF_DATA                   2

  TGF Close                    TGF_CLOSE                  3

  TGF Start                    TGF_START                  4

  TGF Stop                     TGF_STOP                   5

  TGF Pause                    TGF_PAUSE                  6

  TGF End-of-Epoch             TGF_END_OF_EPOCH           7
  ---------------------------- -------------------------- -----------------

##  

## 5.1 SPECIFIC RADAR PACKETS

The following packet types are addressed to a particular radar and are
sent UDP unicast.

### 5.1.1 TGF Open Request

The Open Request allows a Chassis to open and reserve a radar
transmitter for use. One request per radar is sent, prior to the start
of data packet transmission, until all the desired devices are open.
This packet includes the name of the radar, the name of the device, the
type of radar and the scan time. Table 5-2 presents the format of the
information included in an open request packet.

 

[]{#__RefHeading___Toc53286238 .anchor}Table 5-2 TGF Open Request Packet

+-----------------+------------+-------------------+-----------------+
| **Field**       | **Length** | **Format**        | **Value**       |
|                 |            |                   |                 |
|                 | **(Byte)** |                   |                 |
+-----------------+------------+-------------------+-----------------+
| Packet Type     | 4          | Enumeration       | TGF_OPEN        |
+-----------------+------------+-------------------+-----------------+
| Radar Name      | 12         | ASCII String      |                 |
+-----------------+------------+-------------------+-----------------+
| Device Name     | 20         | ASCII String      |                 |
+-----------------+------------+-------------------+-----------------+
| Radar Type      | 4          | Integer           |                 |
+-----------------+------------+-------------------+-----------------+
| Scan Rate       | 4          | Integer           | 1/100 seconds   |
+-----------------+------------+-------------------+-----------------+

#### 

#### 5.1.1.1 Radar Name

The Radar Name is a 12-byte ASCII character field used to uniquely
identify the radar.

 

Examples: \"BAL\", \"DFW\"

 

##### 5.1.1.1.2 Device Name

The Device Name is a 20-byte ASCII character field used to uniquely
identify the device that is to be opened. The Device Name will be in one
of the following formats:

-   rdrtxN

-   rdrrxN

-   ifN

The 'N' represents an integer between zero and the number of devices
that exist.

#### 5.1.1.3 Radar Type

The Radar Type is an integer field that identifies whether the radar is
a transmitter, receiver, or IF. The TGF Chassis will use a transmitter
for radar output.

#### 5.1.1.4 Scan Rate

The Scan Rate is an integer field that represents the time in hundredths
of a second that is required for one complete radar rotation.

### 5.1.2 TGF Open Reply

The TFG Server sends one Open Reply to the requestor for each connection
that the RBX attempted to open. The requestor IP address is obtained
from the UDP header. The Open Reply packet includes the status of the
device, the radar name and any error messages. Table 5-3 presents the
format of the information in the Open Reply packet.

[]{#__RefHeading___Toc53286239 .anchor}Table 5-3 TGF Open Reply Packet

+-------------------+----------+-------------------+------------------+
| **Field**         | **       | **Format**        | **Value**        |
|                   | Length** |                   |                  |
|                   |          |                   |                  |
|                   | **       |                   |                  |
|                   | (Byte)** |                   |                  |
+-------------------+----------+-------------------+------------------+
| Packet Type       | 4        | Enumeration       | TGF_OPEN_REPLY   |
+-------------------+----------+-------------------+------------------+
| Status            | 4        | Integer           |                  |
+-------------------+----------+-------------------+------------------+
| Radar Name        | 12       | ASCII String      |                  |
+-------------------+----------+-------------------+------------------+
| Error Message     | Varied   | ASCII String      |                  |
+-------------------+----------+-------------------+------------------+

#### 

#### 5.1.2.1 Status

The Status is an integer field that signifies whether the device was
successfully opened or not. The status is zero if the device was opened
and less than zero if it could not be opened.

#### 5.1.2.2 Radar Name

The Radar Name is a 12-byte ASCII character field that identifies which
radar the RBX attempted to open.

#### 5.1.2.3 Error Message

The Error Message field contains a message that explains why a device
could not be opened. It is a null terminated ASCII string of variable
length.

### 5.1.3 TGF Data

The TGF Chassis uses the TGF Data packet to transmit radar data through
the RBX for each radar being simulated. This packet includes the name of
the radar, the number of target reports, and messages. Table 5-4
presents the format of the information in the TGF data packets.

** **

[]{#__RefHeading___Toc53286240 .anchor}Table 5-4 TGF Data Packet

+-------------------+------------+----------------------+------------+
| **Field**         | **Length** | **Format**           | **Value**  |
|                   |            |                      |            |
|                   | **(Byte)** |                      |            |
+-------------------+------------+----------------------+------------+
| Radar Name        | 12         | ASCII String         |            |
+-------------------+------------+----------------------+------------+
| Target Reports    | 4          | Integer              |            |
+-------------------+------------+----------------------+------------+
| Messages          | 72         | ASCII String         |            |
+-------------------+------------+----------------------+------------+

####  

#### 5.1.3.1 Radar Name

The Radar Name is a 12-byte ASCII character field that identifies the
radar to which the message is being sent.

#### 5.1.3.2 Target Reports

The Target Reports is an integer field that indicates the number of
radar messages that are included in one packet.

#### 5.1.3.3 Messages

The Message field is actually an array of radar messages. The Target
Reports field indicates the number of messages that are contained in the
Messages packet. Each message has a header followed by the data. The
header includes a time stamp and the type of message that is being sent
to the radar. The actual data is the same as that in a Device Data
Packet. See section 4.4 for a complete description of the information
contained in a data packet. Table 5-5 presents the format of the
information included in the header of the message.

 

[]{#__RefHeading___Toc53286241 .anchor}Table 5-5 TGF Message Header

+-------------------+--------------+------------------+----------------+
| **Field**         | **Length**   | **Format**       | **Value**      |
|                   |              |                  |                |
|                   | **(Byte)**   |                  |                |
+-------------------+--------------+------------------+----------------+
| Message Type      | 4            | Enumeration      |                |
+-------------------+--------------+------------------+----------------+
| Time              | 4            | Integer          | 1/100 seconds  |
+-------------------+--------------+------------------+----------------+

##### 

##### 5.1.3.3.1 Message Type

Message Type is an enumerated integer field that indicates the type of
message that is being sent to the radar.

##### 5.1.3.3.2Time

The Time is an integer field that indicates the simulation time in
hundredths of seconds.

### 

### 

### 5.1.4 TGF Close

The TGF Close packet contains the name of the device that is going to be
closed. The TGF Close message tells the TGF Server to deallocate all
resources for that radar. If the TGF Server has no more open radars, it
will exit. Table 5-6 presents the format of the information included in
the TGF Close packet.

 

[]{#__RefHeading___Toc53286242 .anchor}Table 5-6 TGF Close Packet

+-----------------+----------+----------------------------+------------+
| **Field**       | **       | **Format**                 | **Value**  |
|                 | Length** |                            |            |
|                 |          |                            |            |
|                 | **       |                            |            |
|                 | (Byte)** |                            |            |
+-----------------+----------+----------------------------+------------+
| Packet Type     | 4        | Enumeration                | TGF_CLOSE  |
+-----------------+----------+----------------------------+------------+
| Device Name     | 20       | ASCII String               |            |
+-----------------+----------+----------------------------+------------+

#### 

#### 5.1.4.1 Device Name

Device Name is a 20-byte ASCII character field that is used to identify
the name of the device that is going to be closed. The Device Name will
be in one of the following formats:

-   rdrtxN

-   rdrrxN

-   ifN

The 'N' represents an integer between zero and the number of devices
that exist.

 

## 5.2 GLOBAL PACKETS

Global packets are used by the TGF Server for administration and
control. The following Global packets apply to all radars and are sent
UDP broadcast.

### 5.2.1 TGF Start

A Start packet is sent out to all radars at once to begin a simulation.
The packet contains one field that gives the time in hundredths of
seconds. Every minute the TGF Chassis sends a start containing this time
stamp to maintain synchronization. Table 5-7 presents the format of the
information included in the TGF Start packet.

 

[]{#__RefHeading___Toc53286243 .anchor}Table 5-7 TGF Start Packet

+-----------------+----------------+----------------+-----------------+
| **Field**       | **Length**     | **Format**     | **Value**       |
|                 |                |                |                 |
|                 | **(Byte)**     |                |                 |
+-----------------+----------------+----------------+-----------------+
| Packet Type     | 4              | Enumeration    | TGF_START       |
+-----------------+----------------+----------------+-----------------+
| Time            | 4              | Integer        | 1/100 seconds   |
+-----------------+----------------+----------------+-----------------+

#### 

#### 5.2.1.1 Time

Time is an integer field that indicates the simulation time in
hundredths of seconds.

### 5.2.2 TGF Stop

A Stop packet is sent to all radars at once to end the simulation. The
packet does not contain any additional data. Table 5-8 presents the
format of the information included in the TGF Stop packet.

[]{#tab58 .anchor}

Table 5-8 TGF Stop Packet

+-----------------+----------------+----------------+-----------------+
| **Field**       | **Length**     | **Format**     | **Value**       |
|                 |                |                |                 |
|                 | **(Byte)**     |                |                 |
+-----------------+----------------+----------------+-----------------+
| Packet Type     | 4              | Enumeration    | TGF_STOP        |
+-----------------+----------------+----------------+-----------------+

### 5.2.3 TGF Pause

A Pause packet is sent to all radars at once to freeze the simulation.
The packet does not contain any additional information. Table 5-9
presents the format of the information included in the TGF Pause packet.

 

[]{#__RefHeading___Toc53286245 .anchor}Table 5-9 TGF Pause Packet

+-----------------+----------------+----------------+-----------------+
| **Field**       | **Length**     | **Format**     | **Value**       |
|                 |                |                |                 |
|                 | **(Byte)**     |                |                 |
+-----------------+----------------+----------------+-----------------+
| Packet Type     | 4              | Enumeration    | TGF_PAUSE       |
+-----------------+----------------+----------------+-----------------+

### 

### 5.2.4 TGF End-of-Epoch

An End-of-Epoch packet is sent to the TGF Servers once per second. Each
end-of-epoch packet carries a time stamp that gives the time in
hundredths of seconds. At every end-of-epoch, the RBX flushes all the
information in its master list up to the time stamp given by the
end-of-epoch. Table 5-10 presents the format of the information included
in the TGF End-of-Epoch packet.

 

[]{#__RefHeading___Toc53286246 .anchor}Table 5-10 TGF End-of-Epoch
Packet

+-----------------+----------------+-------------+--------------------+
| **Field**       | **Length**     | **Format**  | **Value**          |
|                 |                |             |                    |
|                 | **(Byte)**     |             |                    |
+-----------------+----------------+-------------+--------------------+
| Packet Type     | 4              | Enumeration | TGF_END_OF_EPOCH   |
+-----------------+----------------+-------------+--------------------+
| Time            | 4              | Integer     | 1/100 seconds      |
+-----------------+----------------+-------------+--------------------+

#### 

#### 

#### 5.2.4.1 Time

Time is an integer field that indicates the simulation time in
hundredths of seconds.

![](media/image5.wmf){width="5.993055555555555in"
height="7.529166666666667in"}

[]{#__RefHeading___Toc53283159 .anchor}Figure 5-1 Radar Transmitter
Communication

# APPENDIX

## 

## APPENDIX A -- Acronym List

 

AAS Advanced Automation System

ACP Azimuth Change Pulses

ATC Air Traffic Control

CTG Core Target Generator

ECO Exercise Control Operator

ECW Exercise Control Workstation

FAA Technical Center Federal Aviation Administration Technical Center

ICD Interface Control Document

IF Interfacility

IOCTL Input / Output Control

IP Internet Protocol

IRQ Interrupt Request

OT&E Operational Test and Evaluation

PCI Peripheral Component Interconnect

PIFD Pseudo Interfacility Device

PRDRRXD Pseudo Radar Receiver Device

PRDRTXD Pseudo Radar Transmitter Device

R&D Research and Development

RBX Radar Box

RBXM Radar Box Monitor

RTQC Real Time Quality Control

SBC Single Board Computer

SCSI Small Computer Systems Interface

TCP Transmission Control Protocol

TGE Target Generator Executive

TGF Target Generation Facility

UDP User Datagram Protocol

## APPENDIX B -- RISCom/8Si Base Address, IRQ, and IO Port Settings

 

> [BASE ADDRESS]{.underline} [IRQ]{.underline} [IO PORT]{.underline}

Card 1 0xD0 None 0x240

 

Card 2 0xD4 None 0x260

 

Card 3 0xD8 None 0x2B0

## APPENDIX C -- Specific RBX Components

  -------------------- --------------------------------------------------
  Motherboard          Asus Motherboard

  Processor            Pentium 120MHZ Microprocessor w/ fan

  DRAM                 32 Meg RAM

  RAM Cache            Internal Cache on CPU

  Hard Disk            Seagate ST32155N 2 gig hard disk

  Controller Card      Adaptec 2940U PCI SCSI

  Video Card           Diamond PCI Video

  Network Option       3Com EC905 10/100 Fast Ethernet PCI Adapter

  System Software      Linux 2.0 (Unix for Intel)

  Enclosure            Silicon Rax SRPC -- 210

  Serial Interface     S18 Serial Boards
  -------------------- --------------------------------------------------

## 

## APPENDIX D -- RBX/Bytex Cable Pinouts

 

![](media/image6.wmf){width="5.990277777777778in"
height="2.759027777777778in"}

## APPENDIX E -- UDP/TCP Port Assignments

** **

  --------------------------- -------------------------- -----------------
  **Process/Machine**         **Port Number**            **UDP/TCP**

  RBXM Monitor                6000                       UDP

  PRDRTXD                     6001                       UDP

  PIFD                        7000                       UDP

  PRDRRXD                     8000                       UDP

  TGF Server                  9050 + Chassis number      UDP
  --------------------------- -------------------------- -----------------

## 

## APPENDIX F -- CD2 Format

## 

## APPENDIX G -- Header File Summaries

** **

**Each of the following header files is located in the tgf/include
directory.**

** **

-   **dev_rbx.h This header file provides the high level interface
    between the TGF and RBX.**

-   **tgf_rbx.h This header file provides a more detailed interface
    between the TGF and RBX.**

-   **if.h This header file contains the message format for
    interfacility communication.**

-   **ifmsgs.h This header file is the wrapper between the IF Device
    Server and the TGF.**