Sie sind auf Seite 1von 116

Radar Receiver

Users Guide

205 Indigo Creek Drive

Rochester, NY 14626

Phone +1.585.256.0200

support@pt.com

w w w. p t . c o m

Document Revision History Part Number


106p0900.10 106p0900.20 106p0900.30 106p0900.31 106p0900.32 106p0900.33 106p0900.40 106p0900.41 106p0900.50 106p0900.51 106p0900.52 106p0900.53

Date
05/28/98 09/30/98 09/07/99 01/10/01 03/07/01 09/09/02 01/29/03 07/09/03 10/17/03 02/09/04 03/26/04 07/29/04

Explanation of changes
Initial Release New Feature Added TPS-75 Protocol Update to Idle non 8-bit pattern and Modem Status Notification Document new functionality in RDR_ERROR_IND Reformatting All Added TPS43C protocol information, Chapter 4, Control Primitives Multiple Updates Added tps43_D Protocol information Added cd_bind_req_t structure modifications and definitions. Modified data format for CD-2, Chapter 4 Added/changed as_bind_req_t, tc_bind_req_t, and cd_bind_req_t structure modifications and definitions, Chapter 4 tc_bind_req_t, and cd_bind_req_t structure modifications and definitions, cd_encoding definitions and tc_encoding definitions Added Raduga-2 Protocol Added Programmable Physical Interface for CPC358 information to Sample Test Programs. Chapter 5, Sample Test Programs Modified cd_purge_committed_data definition, Chapter 4

106p0900.54 106p0900.55 106p0900.56 106p0900.60 106p0900.61

09/21/04 01/31/05 06/08/06 02/16/07 08/03/07

Add support to specify using external clock source for timestamps. Add support to setup optional transmit data acknowledgement timestamps and data. Corrected RDR_CLEAR_TICK, RDR_DATA_ACK, RDR_ERROR_ACK, WANSTRPROT_TS_CLOCK_INACCURATE, cd_bind_req_t structure. Reformatted book. Added WANSTRPROT_OPT1_TX_CLK_INT_RX_CLK_EXTRN (0x00000004) bit definition to RDR_BIND_REQ. Added new parameters to rdrcv and rdrxmt sample programs. Rebranded and reformatted manual. Changed description for as_xunder in as_statistics_t Structure Parameters. Updated RDR_BIND_REQ Response and Reasons for Failure. Added RDR_REISSUE_START on page 58. Added new Test Parameters to the Sample Test Program to support WPS connection type. The following changes have been made on this date: - Changed parameter -M to -F - Added a new parameter -M with its respective description. See Test Parameters on page 108.

106p0900.62

10/26/07

106p0900.63

3/17/08

106p0900.64

07/16/10

106p0900.65

10/19/11

Copyright Notice PT is a trademark of Performance Technologies, Inc. Copyright 2011 by PT. All Rights Reserved.

The PT logo is a registered trademark of PT. All other product and brand names may be trademarks or registered trademarks of their respective owners. This document is the sole property of PT. Disclaimer This document presents information for users of PT products. Although the information contained within this document is considered accurate and characteristic of the subject product, PT reserves the right to make changes to this document and any products described herein to improve reliability, functionality, or design. PT does not assume any liability arising out of the application or use of any product or circuit described herein. No part of this document may be copied or reproduced in any form or by any means without the prior permission of PT. Compliance with RoHS and WEEE Directives In February 2003, the European Union issued Directive 2002/95/EC regarding the Restriction of the use of certain Hazardous Substances in electrical and electronic equipment (RoHS) and Directive 2002/96/EC on Waste Electrical and Electronic Equipment (WEEE). This product is compliant with Directive 2002/95/EC. It may also fall under the Directive 2002/96/EC. PT's complete position statements on the RoHS and WEEE Directives can be viewed on the Web at: http://pt.com/assets/lib/files/pdfs/rohs/policies/rohs-weee-statement.pdf. Errors and Omissions Although diligent efforts are made to supply accurate technical information to the user, occasionally errors and omissions occur in manuals of this type. Refer to the PT Web site to obtain manual revisions or current customer information: http://www.pt.com. PT reserves its right to change product specifications without notice.

Contents

Chapter 1: About This Guide

13

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13 Text Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14 Customer Support and Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14 Customer Support Packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15 Other Web Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15 Return Merchandise Authorization (RMA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15 Product Warranty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15

Chapter 2: Introduction to Radar Receiver

17

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17 Radar Data Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17 Application Programming Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18 System Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18 Overview of DLPI Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19

Chapter 3: Radar Daemon Process

21

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21 Configuration File Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21 Running the Radar Daemon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23

Chapter 4: Control Primitives

25

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25 RDR Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26 RDR_ATTACH_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27 Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27

Contents

Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 New State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Reasons for Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 RDR_DETACH_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 New State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Reasons for Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 RDR_BIND_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 New State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Reasons for Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 RDR_BIND_ACK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 New State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 RDR_UNBIND_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 New State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Reasons for Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 RDR_OK_ACK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Contents

Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .53 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .53 State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .53 New State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .53 RDR_DATA_ACK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .54 Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .54 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .54 State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .55 New State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .55 RDR_ERROR_ACK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56 Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56 State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .57 New State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .57 RDR_REISSUE_START . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .58 Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .58 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .58 State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .58 New State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .58 Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .58 Reasons for Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .58 RDR_ERROR_IND . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .59 Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .59 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .59 State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .60 New State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .60 RDR_CLEAR_TICK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61 Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61 State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61 New State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61 Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61

Contents

Reasons for Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 CD_STATISTICS_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 New State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 Reasons for Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 CD_STATISTICS_ACK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 New State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 AS_STATISTICS_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 New State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 Reasons for Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 AS_STATISTICS_ACK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 New State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 TC_STATISTICS_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 New State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 TC_STATISTICS_ACK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Contents

Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .69 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .69 State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .70 New State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .70 TP_STATISTICS_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .71 Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .71 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .71 State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .71 New State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .71 Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .71 TP_STATISTICS_ACK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .72 Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .72 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .72 State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .73 New State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .73 RADUGA2_STATISTICS_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .74 Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .74 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .74 State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .74 New State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .74 Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .74 RADUGA2_STATISTICS_ACK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .75 Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .75 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .75 State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .77 New State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .77 CD_DATA_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .78 Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .78 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .78 State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .81 New State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .82 Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .82

Contents

Reasons for Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 AS_DATA_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 New State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 Reasons for Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 TC_DATA_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 New State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Reasons for Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 TP_DATA_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 New State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 Reasons for Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 RADUGA2_DATA_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 New State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 Reasons for Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 RDR_DATA_IND . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

10

Contents

A Note About Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .99 Data Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .100 Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .100 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .104 State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .106 New State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .106

Chapter 5: Sample Test Programs

107

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .107 Receive Test Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .107 Transmit Test Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .107 Full Duplex Radar Test Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .107 Test Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .108 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .108 Run the Transmit and Receive Test Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .110 Run the Full Duplex Radar Test Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .114

11

Contents

12

Chapter 1
About This Guide

Overview
This manual covers the following information regarding the Radar Receiver software package: Chapter 2, Introduction to Radar Receiver, on page 17 describes the programming interface to the Radar Receiver (RDR) software package. This interface is derived from the Data Link Provider Interface Specification published by UNIX International. Chapter 3, Radar Daemon Process, on page 21. The RDR software includes a multiplexing module that allows one application connection to receive data from more than one serial line. The serial lines must be configured and initialized before applications can open connections and begin sending or receiving data. A background system-level program, or daemon is supplied to perform this function. Chapter 4, Control Primitives, on page 25 describes the format of each of the supported DLPI primitives for the Radar Receiver protocols. These primitives are used by the application to convey control requests such as the bind, and are used by RDR to provide the application with event indications and responses to control requests. In addition, the primitives are used to receive radar messages. Chapter 5, Sample Test Programs, on page 107 contains examples of the interface to RDR. Three test programs are included in source form with the release and are located in the Radar Client directory.

13

Chapter 1: About This Guide

Text Conventions
This guide uses the following conventions: Convention
Monospace font
Bold font

What it is Used For


Monospace font is used to represent sample code. Bold font is used to represent: pathnames filenames UNIX commands user input

Italic font

Italic font is used to represent: notes that supply useful advice general information referenced documents

$ARCH <> Regular font

Indicates the processor architecture of the target; currently this is ppc, mips, arm and i386. Angle brackets are used to represent variables such as file names, passwords, and so on. Regular font is used for the ENTER and TAB keys and the SPACEBAR on your keyboard.

Customer Support and Services


PT offers a variety of standard and custom support packages to ensure customers have access to the critical resources that they need to protect and maximize hardware and software investments throughout the development, integration, and deployment phases of the product life cycle. If you encounter difficulty in using this PT product, you may contact our support personnel by:
1. EMAIL (Preferred Method) Email us at the addresses listed below or use our online email support form. Outline your problem in detail. Please include your return email address and a telephone number. 2. TELEPHONE Contact us via telephone at the number listed below, and request Technical Support. Our offices are open Monday to Friday, 8:00 a.m. to 8:00 p.m. (Eastern Time).

PT Support Contact Information Embedded Systems and Software (Includes Platforms, Blades, and Servers) Email Phone
support@pt.com +1 (585) 256-0248 (Monday to Friday, 8 a.m. to 8 p.m. Eastern Time)

SS7 Systems (Includes SEGway)


ss7support@pt.com +1 (585) 256-0248 (Monday to Friday, 8 a.m. to 8 p.m. Eastern Time)

If you are located outside North America, we encourage you to contact the local PT distributor or agent for support. Many of our distributors or agents maintain technical support staffs.

14

Product Warranty

Customer Support Packages


Our configurable development and integration support packages help customers maximize engineering results and achieve time-to-market goals. To find out more about our Customer Support packages, visit http://www.pt.com/page/support/.

Other Web Support


Support for existing products including manuals, release notes, and drivers can be found on specific product pages at http://www.pt.com. Use the product search to locate the information you need.

Return Merchandise Authorization (RMA)


To submit a return merchandise authorization (RMA) request, complete the online RMA form available at http://pt.com/assets/lib/files/rma-request-form.doc and follow the instructions on the form. You will be notified with an RMA number once your return request is approved. Shipping information for returning the unit to PT will be provided once the RMA is issued.

Product Warranty
PT warrants that its products sold hereunder will at the time of shipment be free from defects in material and workmanship and will conform to PTs applicable specifications or, if appropriate, to Buyers specifications accepted by PT in writing. If products sold hereunder are not as warranted, PT shall, at its option, refund the purchase price, repair, or replace the product provided proof of purchase and written notice of nonconformance are received by PT within 12 months of shipment, or in the case of software and integrated circuits within ninety (90) days of shipment and provided said nonconforming products are returned F.O.B. to PTs facility no later than thirty days after the warranty period expires. Products returned under warranty claims must be accompanied by an approved Return Material Authorization number issued by PT and a statement of the reason for the return. Please contact PT, or its agent, with the product serial number to obtain an RMA number. If PT determines that the products are not defective, Buyer shall pay PT all costs of handling and transportation. This warranty shall not apply to any products PT determines to have been subject to testing for other than specified electrical characteristics or to operating and/or environmental conditions in excess of the maximum values established in applicable specifications, or have been subject to mishandling, misuse, static discharge, neglect, improper testing, repair, alteration, parts removal, damage, assembly or processing that alters the physical or electrical properties. This warranty excludes all cost of shipping, customs clearance and related charges outside the United States. Products containing batteries are warranted as above excluding batteries. THIS WARRANTY IS IN LIEU OF ALL OTHER WARRANTIES WHETHER EXPRESS, IMPLIED OR STATUTORY INCLUDING IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS. IN NO EVENT SHALL PT BE LIABLE FOR ANY INCIDENTAL OR CONSEQUENTIAL DAMAGES DUE TO BREACH OF THIS WARRANTY OR ANY OTHER OBLIGATION UNDER THIS ORDER OR CONTRACT.

15

Chapter 1: About This Guide

16

Chapter 2
Introduction to Radar Receiver

Overview
This document describes the programming interface to PTs Radar Receiver (RDR) software package. This interface is derived from the Data Link Provider Interface Specification published by UNIX International. Topics included in this chapter include:
Application Programming Interface, on page 18 System Configuration, on page 18 Overview of DLPI Services, on page 19

The Data Link Provider Interface (DLPI) defines a STREAMS-based message interface between a data link service provider (RDR) and an application program. For operation with RDR, PT supports a connectionless mode of service.

Radar Data Formats


The Radar Receiver supports the following radar data formats:
CD-2 (also known as FPS 117) Marconi 10-Bit ASTERIX (also known as Alenia, Selenia, Ericsson, RDIF, RAMP) Thompson-CSF (also known as TPR1000) Thompson-TVT2 Toshiba TPS-43 (can be configured as Common Format) Modified Eurocontrol General 18 Bit NEC Radar Extractor TPS-75 Raduga-2

Readers of this document are assumed to be familiar with the message types and data format of each of the supported radar data formats.

17

Chapter 2: Introduction to Radar Receiver

Application Programming Interface


Applications send and receive DLPI messages using the PT Application Programming Interface (API). The API defines two types of messages. Data messages contain only data. Protocol messages contain a control part and, optionally, a data part. All the messages, or primitives, defined by RDR correspond to the APIs protocol messages. Radar Receiver primitives are sent and received using the APIs MPSputmsg and MPSgetmsg calls. Most primitives have only a control part, which identifies the primitive type and contains associated parameters. Certain control primitives also have a data part, which contains data associated with the primitive. Refer to the document UNIX/Windows NT Application Programming Interface Users Manual for more information on the API.

System Configuration
The Radar Receiver software executes entirely on a PT LAN-based server or intelligent communication controller. Before applications can access the software, it must be loaded to the server or controller, and then configured and initialized by a background system-level program, or daemon. In the case of a LAN-based server that contains more than one serial controller, an instance of the daemon must be executed for each controller. On the controller, the RDR software is organized as a number of separate modules, layered to form streams. Which modules are configured into a particular stream depend on the radar data format being processed by that stream. A lower-level driver module receives HDLC frames or a continuous bit stream from a serial line. A module higher in the stream processes the received data as required by the radar data format. The highest-level module is a multiplexor (radar mux), which allows received messages from multiple serial lines to be forwarded to a single application process. A stream exists below the radar mux for each serial line configured into the system. Applications open connections directly to the radar mux, establishing a stream above the mux for each connection. Figure 2-1 illustrates this concept. To configure the RDR system, the daemon uses the MPSopen API call to open a single connection to the radar mux; specifying protocol name rdrmux, and one connection to the lower-level protocol for each physical link, specifying protocol name cd2, marconi10, asterix, thompcsf, toshiba, tps43, euro, gen18, nec, tps75, or Raduga-2. Using the API's MPSioctl call, the daemon then links each lower-level protocol connection under the radar mux, forming the configuration shown in Figure 2-1, Radar Receiver System Configuration, on page 20. Next, the daemon uses the MPSputmsg API call to send attach requests for each link. With this request, the daemon provides the radar mux with the radar data format type for the link. Once all links are attached, the RDR system is ready for use by application programs. After the daemon has completed its configuration, it can close its connections to the lower-level protocol modules, but must leave its connection to the radar mux open. If this controlling connection is closed, the entire system configuration on the associated controller is dismantled and all links are shut down. For this reason, the daemon must remain in operation as a background process as long as any applications require access to RDR.

18

Overview of DLPI Services

Overview of DLPI Services


Before the Radar Receiver primitives can be used, the application must open a connection to RDR using the MPSopen API call, specifying protocol name rdrmux. A radar swap module is provided with for controllers and servers which interface with a host system which has little endian architecture. It should be pushed onto the stream (using the MPSioctl call) after the open to the radar mux has occurred. Next, the application must bind one or more Data Link Service Access Points (DLSAPs) to the connection. A DLSAP specifies a serial link over which data on the connection is to be transferred. The bind request includes configuration parameters for the data link connection. On receipt of this request, RDR initializes the serial link and enables the receiver. At this point, the application may begin receiving data messages. When data transfer operations are complete, the application should send an unbind request to deactivate the connection and free the associated DLSAP. When interactions between the application and RDR are complete, the application should close the connection using MPSclose. Figure 2-1, Radar Receiver System Configuration, on page 20 shows the Radar Receiver System Configuration.

19

Chapter 2: Introduction to Radar Receiver

Figure 2-1: Radar Receiver System Configuration


Connecon to daemon process

One controlling connecon

Connecons to applicaon

Radar Mux One connecon or stream per link Radar Edit (TCSF) Module

Radar (CD2) Module

ASTERIX Module

Radar (TCSF) Module

Bit Stream Receiver

Bit Stream Receiver

HDLC Driver

Link 0

Link 1

Link 2

20

Chapter 3
Radar Daemon Process

Overview
The RDR software includes a multiplexing module that allows one application connection to receive data from more than one serial line. The serial lines must be configured and initialized before applications can open connections and begin sending or receiving data. A background system-level program, or daemon is supplied to perform this function. Source code for the daemon process, rdrd.c, is included with the RDR release in the Radar Daemon directory. The INSTALL procedure builds the daemon and copies it to /etc (if in the UNIX environment). The daemon reads configuration parameters for each physical link from a text file. A sample configuration file, rdrconfig, is also included in the source code directory and copied to /etc (if in the UNIX environment) by the INSTALL script. The sample file contains default parameters to initialize eight serial links for an assortment of radar protocols. Also provided are configurations which set up the controller for one specific radar protocol. The names of the files reflect the protocol name. You should modify one of these configuration files according to your specific site requirements. The format of the configuration file immediately follows. Running the Radar Daemon on page 23 explains how to run the daemon process. Topics included in this chapter include:
Configuration File Format, on page 21 Running the Radar Daemon, on page 23

Configuration File Format


The daemon process uses the information in the configuration file to configure one or more serial lines on a controller. The parameters specified in the file determine the corresponding parameters of the RDR_ATTACH_REQ primitive, which the daemon sends to the controller during the initialization process. For further information regarding this request and a more detailed description of each parameter, see RDR_ATTACH_REQ, on page 27. Each entry in the configuration file is composed of a parameter keyword followed by a corresponding parameter value. The file is divided into sections, where each section configures a single serial line, and contains an entry for each defined parameter. The following general rules apply:
The first keyword of each section must be link. Other keywords may be listed in any order. Within each section, all keywords must be present and followed by a valid parameter on the same line, separated by white space (one or more spaces and/or tabs). Keywords and parameters may be entered in either upper or lower case. Blank lines and unrecognized entries are ignored.

21

Chapter 3: Radar Daemon Process

The keywords and valid parameter values are listed below.

link protocol

specifies the serial line, numbered from zero. (The maximum valid link number depends on the hardware platform.) determines the radar data format to be used. Valid protocol names are shown in Table 3-1: Valid Protocols:

Table 3-1: Valid Protocols Radar Data Format


CD-2 FPS 117 Marconi 10-Bit ASTERIX Thompson-CSF Thompson-TVT2 Toshiba TPS-43 Modified Eurocontrol General 18-Bit NEC Radar Extractor TPS-75 Raduga-2

Protocol
cd2 cd2 marconi10 asterix thompcsf thompcsf toshiba tps43 euro gen18 nec tps75 raduga-2

A sample configuration file for four serial links is shown below.

link protocol link protocol link protocol link protocol

0 marconi10 1 asterix 2 asterix 3 cd2

22

Running the Radar Daemon

Running the Radar Daemon


The Radar daemon must be executed after the server or communication controller has been downloaded and before any application process attempts to establish a connection to the Radar Receiver. The daemon should be executed in the background, and must not be terminated as long as any applications require access to the Radar Receiver. To run the daemon, use the following command:
rdrd [-f config_file] [-v] [-s server] [-c controller] &

-f config_file

This option can be used to specify the pathname of the configuration file. If this option is not included, the pathname defaults to /etc/ rdrconfig for UNIX, or rdrconfig in the current directory for Windows NT. This option causes the daemon to print status information as it configures and initializes the Radar Receiver. This option identifies the target server. For a LAN-based server, this is the logical host name as specified in the client's hosts database. For a controller installed in a backplane, server is the pathname of the driver's cloneable special file. If this option is not specified, the server name defaults to /dev/ucsclone for UNIX, or \\.\PTIXpqcc for Windows NT. This parameter specifies the controller number. If not specified, controller defaults to 0.

-v -s server

-c controller

23

Chapter 3: Radar Daemon Process

24

Chapter 4
Control Primitives

Overview
This section describes the format of each of the supported DLPI primitives for the Radar Receiver protocols. These primitives are used by the application to convey control requests such as the bind, and are used by RDR to provide the application with event indications and responses to control requests. In addition, the primitives are used to receive radar messages. Topics included in this chapter include:
RDR Primitives, on page 26 RDR_ATTACH_REQ, on page 27 RDR_DETACH_REQ, on page 29 RDR_BIND_REQ, on page 30 RDR_BIND_ACK, on page 51 RDR_UNBIND_REQ, on page 52 RDR_OK_ACK, on page 53 RDR_DATA_ACK, on page 54 RDR_ERROR_ACK, on page 56 RDR_ERROR_IND, on page 59 RDR_CLEAR_TICK, on page 61 CD_STATISTICS_REQ, on page 62 CD_STATISTICS_ACK, on page 63 AS_STATISTICS_REQ, on page 65 AS_STATISTICS_ACK, on page 66 TC_STATISTICS_REQ, on page 68 TC_STATISTICS_ACK, on page 69 TP_STATISTICS_REQ, on page 71 TP_STATISTICS_ACK, on page 72 RADUGA2_STATISTICS_REQ, on page 74 RADUGA2_STATISTICS_ACK, on page 75 CD_DATA_REQ, on page 78 AS_DATA_REQ, on page 82 TC_DATA_REQ, on page 84 TP_DATA_REQ, on page 87 RADUGA2_DATA_REQ, on page 90 RDR_DATA_IND, on page 92

25

Chapter 4: Control Primitives

RDR Primitives
All RDR primitives are sent and received using MPSputmsg and MPSgetmsg, respectively. Most contain only a control part. The following primitives also include a data part:
RDR_BIND_REQ CD_STATISTICS_ACK AS_STATISTICS_ACK TC_STATISTICS_ACK TP_STATISTICS_ACK RDR_DATA_IND

Most primitives are common to all supported radar data formats. The exceptions are as follows:
RDR_BIND_REQ has a common control part, but the data part has a different format depending on the radar type. Different primitives are used to transmit radar data on a serial link, see Table 4-1: RDR Primitives Used to Transmit Radar Data on a Serial Link:

Table 4-1: RDR Primitives Used to Transmit Radar Data on a Serial Link Radar Data Format
CD-2 (FPS 117) Marconi 10-Bit ASTERIX Thompson-CSF Thompson-TVT2 Toshiba TPS-43 Modified Eurocontrol General 18-Bit NEC Radar Extractor TPS-75 Raduga-2

RDR Primitive Used


CD_DATA_REQ CD_DATA_REQ AS_DATA_REQ TC_DATA_REQ TC_DATA_REQ TC_DATA_REQ TP_DATA_REQ CD_DATA_REQ CD_DATA_REQ CD_DATA_REQ TP_DATA_REQ RADUGA2_DATA_REQ

RDR_DATA_IND provides the application with all types of received radar messages. The format of each radar message within the data part depends on the radar data format configured for the serial link on which the message was received. Different primitives are used to request and provide statistical information about a serial link, see Table 4-2: RDR Primitives Used to Request Statistics About a Serial Link:

Table 4-2: RDR Primitives Used to Request Statistics About a Serial Link Radar Data Format
CD-2 (FPS 117) Marconi 10-Bit ASTERIX Thompson-CSF Thompson-TVT2

Primitive Used to Request Statistics


CD_STATISTICS_REQ CD_STATISTICS_REQ AS_STATISTICS_REQ TC_STATISTICS_REQ TC_STATISTICS_REQ

Primitive That Provides Statistics


CD_STATISTICS_ACK CD_STATISTICS_ACK AS_STATISTICS_ACK TC_STATISTICS_ACK TC_STATISTICS_ACK

26

RDR_ATTACH_REQ

Table 4-2: RDR Primitives Used to Request Statistics About a Serial Link
Toshiba TPS-43 Modified Eurocontrol General 18-Bit NEC Radar Extractor TPS-75 Raduga-2 TC_STATISTICS_REQ TP_STATISTICS_REQ CD_STATISTICS_REQ CD_STATISTICS_REQ CD_STATISTICS_REQ TP_STATISTICS_REQ RADUGA2_STATISTICS_REQ TC_STATISTICS_ACK TP_STATISTICS_ACK CD_STATISTICS_ACK CD_STATISTICS_ACK CD_STATISTICS_ACK TP_STATISTICS_ACK RADUGA2_STATISTICS_ACK

Each primitive description in this section includes a structure definition for the control part of the message. The structure definitions vary, but the first field always specifies the primitive type. The primitive type determines the format of the remainder of the message. The message types and structures referenced in this section are defined in the files dlpirdr.h, dlpiast.h, dlpicd2.h, dlpitcsf.h, dlpitps43.h, and dlpiraduga2.h. These files use typedefs defined in the include file xstypes.h located in the include directory.

RDR_ATTACH_REQ
To configure the Radar Receiver system on a communication controller, the daemon program (see Running the Radar Daemon, on page 23) must:
Open a connection to the radar protocol module for each physical link to be configured. Push the radar swap module if the system requires it (little endian architecture). Open a single connection to the radar mux module. For each radar protocol connection, use the APIs MPSioctl call to send a request of type X_LINK to the radar mux, linking the protocol connection underneath the radar mux. Send an attach request to the radar mux for each radar protocol connection (one for each physical link).

The RDR_ATTACH_REQ message is sent by the daemon to request that RDR attach a physical link to the connection. This request informs the radar mux of the protocol type (radar data format) assigned to each of its lower-level streams. Once a link has been attached to a connection, it cannot be attached to any other connection until an RDR_DETACH_REQ is processed on the original connection.

Message Format
The control part of this message is defined by the following structure: typedef struct { bit32 rdr_primitive; bit32 rdr_link; bit32 rdr_l_index; char rdr_protocol[24]; } rdr_attach_req_t; There is no data part.

27

Chapter 4: Control Primitives

Parameters
rdr_primitive rdr_link conveys RDR_ATTACH_REQ. identifies the serial link that will be associated with the connection. Links are numbered beginning at zero. (The maximum link number depends on the hardware platform.) must specify the link ID that was returned from the MPSioctl X_LINK request. is an ASCII string identifying the radar data format associated with the connection, as follows: cd2 marconi10 asterix thompcsf thompcsf toshiba tps43 euro gen18 nec tps75 raduga2 CD-2 or FPS 117 Marconi 10-Bit ASTERIX Thompson-CSF Thompson-TVT2 Toshiba TPS-43 Modified Eurocontrol General 18-Bit NEC Radar Extractor TPS-75 Raduga-2

rdr_l_index rdr_protocol

State
This message is valid in state RDR_NOTATTACHED.

New State
The resulting state is RDR_ATTACH_PENDING.

Response
When RDR successfully processes the attach request, it sends RDR_OK_ACK to the application and the resulting state is RDR_UNBOUND. If the request is in error, RDR returns RDR_ERROR_ACK instead and the state reverts to RDR_NOTATTACHED. In either case, the rdr_modifier field of the returned primitive identifies the serial link (rdr_link).

28

RDR_DETACH_REQ

Reasons for Failure


RDR_ATTACHED RDR_NOSUCHPROTOCOL RDR_NOTAUTHOR Requested physical link is already attached. rdr_protocol string is invalid. Link ID specified in rdr_l_index is invalid.

RDR_DETACH_REQ
This message is sent by the background daemon process to request RDR to detach the physical link that was previously attached to the connection with an RDR_ATTACH_REQ. This message is normally sent by the daemon only when it is shutting down the Radar Receiver system before exiting. Any applications with an open connection to RDR on the specified serial link will receive disconnect indications.

Message Format
The control part of the message is defined by the following structure: typedef struct { bit32 rdr_primitive; bit32 rdr_link; } rdr_primitive; There is no data part.

Parameters
rdr_primitive rdr_link conveys RDR_DETACH_REQ. specifies the serial link to be detached.

State
This message is valid in state RDR_UNBOUND or RDR_DATAXFER.

New State
The resulting state is RDR_DETACH_PENDING.

Response
In response, RDR sends RDR_OK_ACK to the application and the new state is RDR_NOTATTACHED. If the request is in error, RDR_ERROR_ACK is returned instead and the state reverts to the state from which the RDR_DETACH_REQ was issued.

29

Chapter 4: Control Primitives

Reasons for Failure


RDR_INVALIDPORT The link number specified in rdr_link is invalid.

RDR_BIND_REQ
This message is sent by the application to request that RDR bind a DLSAP to the connection. This request configures and enables the associated serial link. The radar mux allows multiple DLSAPs to be bound to a single connection. However, once a DLSAP has been bound to a connection, it cannot be bound to any other connection until a RDR_UNBIND_REQ is processed on the original connection.

Message Format
The control part of this message is defined by the following structure: typedef struct { bit32 bit32 char bit32 bit32 wanStrProt_txDataAcks_t wanStrProt_options1_t } rdr_bind_req_t;

rdr_primitive; rdr_link; rdr_protocol[24]; rdr_max_messages; rdr_message_timeout; rdr_data_acks; rdr_options1;

See rdr_bind_req_t Structure Parameters, on page 34 for a description of each parameter. The data part of the message contains protocol-specific configuration parameters. Each data part is described below:

30

RDR_BIND_REQ

CD-2 (FPS 117), Marconi 10-Bit, Modified Eurocontrol, General 18-Bit and NEC Radar Extractor Data Part
The data part of the message contains protocol-specific configuration parameters. For CD-2 (FPS 117), Marconi 10-Bit, Modified Eurocontrol, General 18-Bit and NEC Radar Extractor, the data part is defined by the following structure: typedef struct { bit32 bit32 bit32 bit32 bit32 bit32 bit32 bit32 bit32 bit32 bit32 bit32 bit32 bit32 bit32 bit32 wanStrProt_phyIf_t bit32 bit32 bit32 wanStrC_serRxTxEncode_t bit32 } cd_bind_req_t;

cd_primitive; cd_link; cd_baud; cd_timeout_baud; cd_packmesg; cd_maxmesg_size; cd_maxmesg_cnt; cd_fwd_time; cd_dma_blocksize; cd_contype; cd_sync; cd_invert; cd_do_idle; cd_idle_pattern; cd_modem_in; cd_sigtimeout; phyIf; cd_xmt_unpackmesg; cd_xmt_idles; cd_purge_committed_data; cd_encoding; cd_idle_buf_to;

See cd_bind_req_t Structure Parameters, on page 36 for a description of each parameter.

ASTERIX Data Part


For ASTERIX, the data part is defined by the following structure: typedef struct { bit32 bit32 bit32 bit32 bit32 bit32 dlpiAst_phyIf_t wanStrProt_txDataAcks_t bit32

as_link; as_framesize; as_baud; as_encoding; as_mode; as_modem; phyIf; as_data_acks; as_purge_committed_data;

31

Chapter 4: Control Primitives

bit32 bit32 } as_bind_req_t;

as_timeout_baud; as_fwd_time;

See as_bind_req_t Structure Parameters, on page 39 for a description of each parameter.

Thompson-CSF, Thompson-TVT2 and Toshiba Data Part


For Thompson-CSF, Thompson-TVT2 and Toshiba, the data part is defined as follows: typedef struct { bit32 bit32 bit32 bit32 bit32 bit32 bit32 bit32 bit32 bit32 bit32 bit32 bit32 bit32 bit32 wanStrProt_phyIf_t bit32 wanStrC_serRxTxEncode_t bit32 } tc_bind_req_t;

tc_primitive; tc_link; tc_baud; tc_timeout_baud; tc_maxmesg_size; tc_maxmesg_cnt; tc_fwd_time; tc_dma_blocksize; tc_contype; tc_sync; tc_check_crc; tc_time_delay; tc_variant; tc_modem_in; tc_sigtimeout; phyIf; tc_purge_committed_data; tc_encoding; tc_idle_buf_to;

See tc_bind_req_t Structure Parameters, on page 41 for a description of each parameter.

32

RDR_BIND_REQ

TPS-43 and TPS-75 Data Part


For TPS-43 and TPS-75, the data part is defined as follows: typedef struct { bit32 bit32 bit32 bit32 bit32 bit32 bit32 bit32 bit32 bit32 bit32 bit32 bit32 bit32 wanStrProt_phyIf_t bit32 bit32 wanStrC_serRxTxEncode_t bit32 bit32 } tp_bind_req_t;

tp_primitive; tp_link; tp_baud; tp_timeout_baud; tp_maxmesg_size; tp_maxmesg_cnt; tp_fwd_time; tp_dma_blocksize; tp_contype; tp_sync; tp_idle; tp_modem_in; tp_sigtimeout; tp_relaxed_data_gathering; phyIf; tp_error_info; tp_purge_committed_data; tp_encoding; tp_idle_buf_to; tp_enhanced

See tp_bind_req_t Structure Parameters, on page 44 for a description of each parameter.

33

Chapter 4: Control Primitives

Raduga-2 Data Part


For Raduga-2, the data part is defined as follows: typedef struct { bit32 bit32 bit32 bit32 bit32 bit32 bit32 bit32 bit32 bit32 bit32 bit32 bit32 bit32 bit32 bit32 wanStrProt_phyIf_t bit32 wanStrC_serRxTxEncode_t bit32 } raduga2_bind_req_t;

raduga2_primitive; raduga2_link; raduga2_baud; raduga2_timeout_baud; raduga2_maxmesg_size; raduga2_maxmesg_cnt; raduga2_fwd_time; raduga2_dma_blocksize; raduga2_contype; raduga2_sync; raduga2_check_crc; raduga2_check_parity; raduga2_modem_in; raduga2_sigtimeout; raduga2_do_idle; raduga2_idle_pattern; phyIf; raduga2_purge_committed_data; raduga2_encoding; cd_idle_buf_to;

See raduga2_bind_req_t Structure Parameters, on page 46 for a description of each parameter.

Parameters
rdr_bind_req_t Structure Parameters
The rdr_bind_req_t structure defines the control part of the message for all radar data formats: rdr_primitive rdr_link conveys RDR_BIND_REQ. identifies the DLSAP that will be bound to the connection. A DLSAP is equivalent to a link number, where links are numbered beginning at zero. (The maximum link number depends on the hardware platform.) is an ASCII string identifying the radar data format configured for the associated serial link, as follows: cd2 marconi10 asterix thompcsf CD-2 or FPS 117 Marconi 10-Bit ASTERIX Thompson-CSF

rdr_protocol

34

RDR_BIND_REQ

thompcsf toshiba tps43 euro gen18 nec tps75 raduga2 rdr_max_messages

Thompson-TVT2 Toshiba TPS-43 Modified Eurocontrol General 18-Bit NEC Radar Extractor TPS-75 Raduga-2

configures the maximum number of received radar messages, from all DLSAPs bound to the connection, that will be accumulated by the radar mux before they are forwarded to the application in the data portion of an RDR_DATA_IND primitive. If more than one DLSAP is bound to a single connection, this parameter should have the same value in each RDR_BIND_REQ.

rdr_message_timeout specifies the length of time, in increments of one hundred milliseconds, RDR waits before sending an RDR_DATA_IND primitive to the application when rdr_max_messages has not been reached. rdr_data_acks specifies whether or not acknowledgments are sent, and what is included in the acknowledgement, in response to DATA_REQ primitives. This option only applies to links that are configured in writeonly and readwrite mode. This parameter is an enumeration and is treated as a bit field where more than one feature can be or'd together. The bit definitions are:
WANSTRPROT_TX_DATA_ACKS_DISABLE (0x0000000)

Disables acknowledgements.
WANSTRPROT_TX_DATA_ACKS_ENABLE (0x00000001)

Enable acknowledgments.
WANSTRPROT_TX_DATA_ACKS_WITH_TIMESTAMPS (0x00000002)

Includes valid timestamp in the acknowledgement information. This option only applies to the NexusWare base Protocol controllers.
WANSTRPROT_TX_DATA_ACKS_WITH_DATA (0x00000004)

Includes the requested message to transmit in the acknowledgement information. This option only applies to the NexusWare base Protocol controllers. See the applicable Radar Protocol DATA_REQ for further information on Data Acknowledgements. rdr_options1 This parameter is an enumeration and is treated as a bit field where more than one feature can be or'd together. The bit definitions are:
WANSTRPROT_OPT1_END_OF_MSG_TIMESTAMPS (0x00000001)

35

Chapter 4: Control Primitives

Derive timestamp when end of message is detected. If not specified, the timestamp is derived for the beginning of message. This option only applies to the NexusWare base Protocol controllers.
WANSTRPROT_OPT1_EXTERN_CLK_TIMESTAMPS (0x00000002)

Enables the use of a highly accurate external time of day source that is a separate hardware unit that can be present in the MPS system. Refer to the Multi-Protocol Time-Tagging Server (MPTTS) Reference Manual for more details on this. If not specified, then the system time of day source from the controller's CPU will be used.
WANSTRPROT_OPT1_TX_CLK_INT_RX_CLK_EXTRN (0x00000004)

Enables the transmit clock to be generated internally at the baud rate specified above and the receive clock to be obtained from the external line.

cd_bind_req_t Structure Parameters


The cd_bind_req_t structure defines the data part of the message for CD-2 (FPS 117), Marconi 10-Bit, Modified Eurocontrol, General 18-Bit and NEC Radar Extractor: cd_primitive cd_link not used. identifies the DLSAP that will be bound to the connection. This parameter must have the same value as the rdr_link field in the control part of the message. specifies the line speed for the connection. A value of -1 for this parameter configures the link for external clocking, meaning that the transmit clock must be supplied by an external device (such as a modem). The receive clock signal is configured as an input (supplied by the transmitting device or other external device). For a normal receive-only connection, cd_baud should always be set to -1. cd_timeout_baud specifies the line speed in bits/second. For example, if the line speed is 2400 bps, cd_timeout_baud should be set to 2400. This value is used to calculate the time stamp for received messages and is not used for a transmit-only connection. determines how RDR will format radar messages within the data portion of RDR_DATA_IND primitives, as follows: 0 Data is unpacked. For CD-2 and Marconi 10-Bit, this means that each 16-bit word of the message contains one 10- or 13-bit word of radar data, with the unused upper bits set to zero. For Modified Eurocontrol and General 18-Bit, unpacked format means that each 32-bit long word of the message contains one 18-bit word of radar data, with the unused upper 14 bits set to zero.

cd_baud

cd_packmesg

36

RDR_BIND_REQ

Data is packed, meaning that bits of consecutive words of radar data are contiguous within the 16-bit words of the message.

This format option is not used for the NEC Radar Extractor Protocol since it is processed in 8-bit bytes. These data formatting options are described in more detail in RDR_DATA_IND, on page 92. cd_maxmesg_size specifies the number of bytes required to store the maximum-length radar message in the selected data format. For example, if the maximum radar message size is 7 13-bit words, cd_maxmesg_size should be set to 14 if cd_packmesg is 0; or 12 if cd_packmesg is 1. RDR uses this value to identify errors in received data and to format messages within the data portion of RDR_DATA_IND primitives. defines the maximum number of data messages that will be accumulated by the radar protocol module before they are forwarded to the radar mux. specifies the length of time, in increments of one hundred milliseconds, the radar protocol module waits before sending a block of received messages to the radar mux when cd_maxmesg_cnt has not been reached. determines the number of 8-bit bytes to be received before the data is processed (assembled into messages and forwarded to the application). Blocks of the specified size are received by the serial device driver and passed to a radar protocol module for processing. A very small block size decreases the efficiency of the serial device driver, while a large block size increases the latency of received messages. (The time stamp on each message is always accurate, regardless of the configured block size.) cd_contype specifies RDR_READONLY for normal receive-only operation, RDR_WRITEONLY to transmit data, or RDR_READWRITE which allows reading and writing on the same link (QUICC platforms only). for all protocols except GENERAL 18-Bit, this parameter is reserved and should be set to zero. For General 18-Bit, this parameter should be set to the desired 18-bit sync pattern. configures the link for data bit inversion, as follows: 0 1 No inversion Invert data bits

cd_maxmesg_cnt

cd_fwd_time

cd_dma_blocksize

cd_sync

cd_invert

If data bit inversion is selected, a ones complement operation is performed on all data after reception or before transmission. cd_do_idle specifies that the Radar Protocol should idle out of the non 8-bit idle pattern defined in the cd_idle_pattern. If set, the protocol will construct the minimum sized buffer that will contain the non 8-bit idle pattern without padding to the end of a byte. This is not applicable for links set to READONLY.

37

Chapter 4: Control Primitives

cd_idle_pattern

user specified non 8-bit idle sequence (in lieu of the standard 8-bit idle character) for CD-2, Marconi 10-bit, Modified Eurocontrol, or General 18-bit protocols, when no radar data is being transmitted on the serial link. specifies how the SBSI driver should handle changes in modem input signals during link operation: RDR_NO_SIGS, changes in modem signals are ignored by the driver. RDR_SIGS, the driver will notify upstream modules when there is a change in modem input signals via a RDR_ERROR_IND with rdr_errno equal to either RDR_LINKUP or RDR_LINKDOWN.

cd_modem_in

cd_sigtimeout

specifies the amount of time (in10ms increments) to delay before processing a modem signal interrupt (normally referred to as debounce time). This parameter applies only if the cd_modem_in parameter is set to RDR_SIGS. The phyIf field configures the physical interface of a CPC358. It is ignored by all other products. The supported interfaces and their respective values are: V. 11 RS530A RS530 X.21 V.35 RS449 RS232 HIZ WANSTRPROT_PHYIF_V11 or 0 WANSTRPROT _PHYIF_RS530A or 1 WANSTRPROT _PHYIF_RS530 or 2 WANSTRPROT _PHYIF_X21 or 3 WANSTRPROT _PHYIF_V35 or 4 WANSTRPROT _PHYIF_RS449 or 5 WANSTRPROT _PHYIF_RS232 or 6 WANSTRPROT _PHYIF_HIZ or 7

phyIf

cd_xmt_unpackmesg for all protocols except NEC Radar, determines how RDR will interpret the format of radar messages within the data portion of CD_DATA_REQ primitives, as follows: 0 Data is packed, meaning that bits of consecutive words of radar data are contiguous within the 16-bit words of the message. Data is unpacked. For CD-2 this means that each 16-bit word of the message contains a 13-bit word of radar data, with the upper three bits unused.

cd_xmt_idles

for all protocols except NEC Radar, determines if RDR will insert idle words between messages to be transmitted. If idles are inserted, the CD-2 protocol will format the total number of data bytes to end on a 13bit boundary. 0 Do not insert idle words between messages to be transmitted. Assume the data portion of the CD_DATA_REQ primitive includes them.

38

RDR_BIND_REQ

Insert idle words between messages to be transmitted.

cd_purge_committed_data specifies whether the transmit BDs will be immediately purged of data when CTS/DCD go down. This parameter should be used in conjunction with cd_data_acks and cd_noclock_to to ensure that stale data is not left on the controller when CTS/DCD go back up. The preferred data purging mechanism is to use cd_noclock_to solely. This feature applies to xSTRa based platforms only. cd_encoding specifies the type of encoding for the link (NexusWare platforms only), which is defined by the following structure:
typedef enum _wanStrC_serRxTxEncode_t { WANSTRC_SER_RXTX_ENC_NRZ, WANSTRC_SER_RXTX_ENC_NRZ_INV, WANSTRC_SER_RXTX_ENC_NRZI_MARK, WANSTRC_SER_RXTX_ENC_NRZI_SPACE, WANSTRC_SER_RXTX_ENC_FM0, WANSTRC_SER_RXTX_ENC_FM1, WANSTRC_SER_RXTX_ENC_MANCHESTER, WNASTRC_SER_RXTX_ENC_DIFF_MANCHESTER } wanStrC_serRxTxEncode_t;

cd_idle_buf_to

This parameter determines the amount of time (in tenths of a second) allowed for transmission of an non 8-bit idle buffer when transmit data acknowledgements are enabled. This parameter applies to NexusWare based platforms only.

as_bind_req_t Structure Parameters


The as_bind_req_t structure defines the data part of the message for ASTERIX: as_link identifies the DLSAP that will be bound to the connection. This parameter must have the same value as the rdr_link field in the control part of the message. configures the maximum size of an ASTERIX message. specifies the line speed for the connection. A value of -1 for this parameter configures the link for external clocking, meaning that the transmit clock must be supplied by an external device (such as a modem). The receive clock signal is configured as an input (supplied by the transmitting device or other external device). For a normal receive-only connection, cd_baud should always be set to -1. as_encoding data encoding for the link as follows: 0 1 2 NRZ NRZI FM0 for RAMP Radar (QUICC platform only)

as_framesize as_baud

39

Chapter 4: Control Primitives

3 4 5 as_mode as_modem

FM1 (QUICC platforms only) Manchester (QUICC platforms only) Differential Manchester (QUICC platforms only)

must be set to 0. determines whether the serial device driver requires the clear to send (CTS) and data carrier detect (DCD) modem signals, as follows: 1 0 Link initialization fails if the device driver does not detect CTS and DCD within 90 seconds. Link initialization succeeds regardless of whether CTS and DCD are present.

The device driver always turns on the request to send (RTS) and data terminal ready (DTR) signals when it initializes the serial link. phyIf The phyIf field configures the physical interface of a CPC358. It is ignored by all other products. The supported interfaces and their respective values are: V. 11 RS530A RS530 X.21 V.35 RS449 RS232 HIZ as_data_acks DLPIAST_PHYIF_V11 or 0 DLPIAST_PHYIF_RS530A or 1 DLPIAST_PHYIF_RS530 or 2 DLPIAST_PHYIF_X21 or 3 DLPIAST_PHYIF_V35 or 4 DLPIAST_PHYIF_RS449 or 5 DLPIAST_PHYIF_RS232 or 6 DLPIAST_PHYIF_HIZ or 7

specifies whether or not acknowledgments are sent, and what is included in the acknowledgement, in response to DATA_REQ primitives. This option only applies to links that are configured in writeonly and readwrite mode. This parameter is an enumeration and is treated as a bit field where more than one feature can be or'd together. The bit definitions are:
WANSTRPROT_TX_DATA_ACKS_DISABLE (0x0000000)

Disables acknowledgements.
WANSTRPROT_TX_DATA_ACKS_ENABLE (0x00000001)

Enable acknowledgments
WANSTRPROT_TX_DATA_ACKS_WITH_TIMESTAMPS (0x00000002)

Includes valid timestamp in the acknowledgement information. This option only applies to the NexusWare base Protocol controllers.
WANSTRPROT_TX_DATA_ACKS_WITH_DATA (0x00000004)

40

RDR_BIND_REQ

Includes the requested message to transmit in the acknowledgement information. This option only applies to the NexusWare base Protocol controllers. See AS_DATA_REQ, on page 82 for further information on Data Acknowledgements. as_purge_committed_data specifies whether the transmit BDs will be immediately purged of data when CTS/DCD go down. This parameter should be used in conjunction with as_data_acks and as_noclock_to to ensure that stale data is not left on the controller when CTS/DCD go back up. The preferred data purging mechanism is to use as_noclock_to solely. This feature applies to xSTRa based platforms only. as_timeout_baud specifies the line speed in bits/second. For example, if the line speed is 2400 bps, as_timeout_baud should be set to 2400. This value is used to calculate the time stamp for received messages. specifies the length of time, in increments of one hundred milliseconds, the radar protocol module waits before sending an empty message to the radar mux when no radar messages have been received.

as_fwd_time

tc_bind_req_t Structure Parameters


The tc_bind_req_t structure defines the data part of the message for Thompson-CSF, Thompson-TVT2 and Toshiba: tc_primitive tc_link not used. identifies the DLSAP that will be bound to the connection. This parameter must have the same value as the rdr_link field in the control part of the message. specifies the line speed for the connection. A value of -1 for this parameter configures the link for external clocking, meaning that the transmit clock must be supplied by an external device (such as a modem). The receive clock signal is configured as an input (supplied by the transmitting device or other external device). For a normal receive-only connection, cd_baud should always be set to -1. tc_timeout_baud specifies the line speed in bits/second. For example, if the line speed is 2400 bps, tc_timeout_baud should be set to 2400. This value is used to calculate the time stamp for received messages. In the Toshiba radar protocol, this value is also used in conjunction with the desired time delay value (tc_fwd_time) to calculate how much idle padding to append to a transmitted message. specifies the maximum length of a received Thompson-CSF, Thompson-TVT2 or a Toshiba radar message, in bytes.

tc_baud

tc_maxmesg_size

41

Chapter 4: Control Primitives

For a Thompson-CSF and Thompson-TVT2 radar messages, the specified length must include the two-byte header, BSC control characters, CRC bytes and any expansion of the data for transparency. To determine the correct value for this parameter, double the expected maximum data size (for transparency) and add 12 (for the header, control characters and CRC). For a Toshiba radar message, the specified length must include the BSC control characters, CRC bytes and any expansion of the data for transparency. To determine the correct value for this parameter, double the expected maximum data size (for transparency) and add 9 (for the header, control characters and CRC). tc_maxmesg_cnt defines the maximum number of data messages that will be accumulated by the radar protocol module before they are forwarded to the radar mux. specifies the length of time, in increments of one hundred milliseconds, the radar protocol module waits before sending a block of received messages to the radar mux when tc_maxmesg_cnt has not been reached. determines the number of 8-bit bytes to be received before the data is processed (assembled into messages and forwarded to the application). Blocks of the specified size are received by the serial device driver and passed to a radar protocol module for processing. A very small block size decreases the efficiency of the serial device driver, while a large block size increases the latency of received messages. (The time stamp on each message is always accurate, regardless of the configured block size.) tc_contype specifies RDR_READONLY for normal receive-only operation, RDR_WRITEONLY to transmit data, or RDR_READWRITE which allows reading and writing on the same link (QUICC platforms only). specifies the hexadecimal value of the sync character; 0x32 for Thompson-CSF and Toshiba, and 0x16 for Thompson-TVT2. configures CRC checking for received messages as follows: 0 1 tc_time_delay Ignore CRC Discard messages with CRC errors

tc_fwd_time

tc_dma_blocksize

tc_sync tc_check_crc

This parameter has a special purpose for a transmit link configured for the Toshiba radar protocol. The time delay value in milliseconds is specified with this parameter. This will allow the client transmit program to specify a minimum time gap between successive messages. The radar protocol will calculate the number of idle characters (based on the baud rate and the time delay desired) to append to each message transmitted. specifies the type of Thompson radar format (not used by Toshiba) as follows:

tc_variant

42

RDR_BIND_REQ

THOMP_A THOMP_B tc_modem_in

Thompson-CSF Thompson-TVT2

specifies how the SBSI driver should handle changes in modem input signals during link operation: RDR_NO_SIGS, changes in modem signals are ignored by the driver. RDR_SIGS, the driver will notify upstream modules when there is a change in modem input signals via a RDR_EROR_IND with rdr_errno equal to either RDR_LINKUP or RDR_LINKDOWN.

tc_sigtimeout

specifies the amount of time (in10ms increments) to delay before processing a modem signal interrupt (normally referred to a debounce time). This parameter applies only if the tc_modem_in parameter is set to set to RDR_SIGS. The phyIf field configures the physical interface of a CPC358. It is ignored by all other products. The supported interfaces and their respective values are: V. 11 RS530A RS530 X.21 V.35 RS449 RS232 HIZ DLPIAST_PHYIF_V11 or 0 DLPIAST_PHYIF_RS530A or 1 DLPIAST_PHYIF_RS530 or 2 DLPIAST_PHYIF_X21 or 3 DLPIAST_PHYIF_V35 or 4 DLPIAST_PHYIF_RS449 or 5 DLPIAST_PHYIF_RS232 or 6 DLPIAST_PHYIF_HIZ or 7

phyIf

tc_purge_committed_data specifies whether the transmit BDs will be immediately purged of data when CTS/DCD go down. This parameter should be used in conjunction with tc_data_acks and tc_noclock_to to ensure that stale data is not left on the controller when CTS/DCD go back up. The preferred data purging mechanism is to use tc_noclock_to solely. This feature applies to xSTRa based platforms only. tc_encoding specifies the type of encoding for the link (NexusWare platforms only), which is defined by the following structure:
typedef enum _wanStrC_serRxTxEncode_t { WANSTRC_SER_RXTX_ENC_NRZ, WANSTRC_SER_RXTX_ENC_NRZ_INV, WANSTRC_SER_RXTX_ENC_NRZI_MARK, WANSTRC_SER_RXTX_ENC_NRZI_SPACE, WANSTRC_SER_RXTX_ENC_FM0, WANSTRC_SER_RXTX_ENC_FM1, WANSTRC_SER_RXTX_ENC_MANCHESTER, WNASTRC_SER_RXTX_ENC_DIFF_MANCHESTER

43

Chapter 4: Control Primitives

} wanStrC_serRxTxEncode_t;

tc_idle_buf_to

this parameter determines the amount of time (in tenths of a second) allowed for transmission of an non 8-bit idle buffer when transmit data acknowledgements are enabled. This parameter applies to NexusWare based platforms only.

tp_bind_req_t Structure Parameters


The tp_bind_req_t structure defines the data part of the message for TPS-43 and TPS-75: tp_primitive conveys which variant of TPS-43: TPS43_A which consists of two start groups, fourteen data groups, and one odd parity group, TPS43_B and TPS43_D (also known as Link-1) which consists of one start group, 14 data groups (each with a mark bit), and one odd parity group, or TPS43_C (also known as Common Format) which consists of one start group, and one odd parity group in the middle of 14 data groups (each with a mark bit). This parameter is not used for TPS-75. identifies the DLSAP that will be bound to the connection. This parameter must have the same value as the rdr_link field in the control part of the message. specifies the line speed for the connection. A value of -1 for this parameter configures the link for external clocking, meaning that the transmit clock must be supplied by an external device (such as a modem). The receive clock signal is configured as an input (supplied by the transmitting device or other external device). For a normal receive-only connection, cd_baud should always be set to -1. tp_timeout_baud specifies the line speed in bits/second. For example, if the line speed is 2400 bps, tp_timeout_baud should be set to 2400. This value is used to calculate the time stamp for received messages. specifies the maximum length of a block of data which the TPS-43 or TPS-75 radar will divide up and build into data messages to transmit. Since the transmitted data messages are fixed in size (17 bytes for TPS-43 variant A, 16 bytes for TPS-43 variant B, variant C and variant D, and 18 bytes for TPS-75), the value for tp_maxmesg_size should be an even multiple of the data size. defines the maximum number of data messages that will be accumulated by the radar protocol module before they are forwarded to the radar mux. specifies the length of time, in increments of one hundred milliseconds, the radar protocol module waits before sending a block of received messages to the radar mux when tp_maxmesg_cnt has not been reached.

tp_link

tp_baud

tp_maxmesg_size

tp_maxmesg_cnt

tp_fwd_time

44

RDR_BIND_REQ

tp_dma_blocksize

determines the number of 8-bit bytes to be received before the data is processed (assembled into messages and forwarded to the application). Blocks of the specified size are received by the serial device driver and passed to a radar protocol module for processing. A very small block size decreases the efficiency of the serial device driver, while a large block size increases the latency of received messages. (The time stamp on each message is always accurate, regardless of the configured block size.)

tp_contype

specifies RDR_READONLY for normal receive-only operation, RDR_WRITEONLY to transmit data, or RDR_READWRITE which allows reading and writing on the same link (QUICC platforms only). specifies the hexadecimal value of the start group (normally 0x68 for TPS43_A, 0x00 for TPS43_B, TPS43_C and TPS43_D, and 0x0000 for TPS-75). specifies the hexadecimal value of the character which the line will idle when no data is currently being transmitted (normally 0xAA for TPS43_A, 0x55 for both TPS43_B and TPS-75, and 0xFF for TPS43_C and TPS43_D). This parameter is only used when the tp_contype is set to RDR_READWRITE (see the parameter tp_contype, above). specifies how the SBSI driver should handle changes in modem input signals during link operation: RDR_NO_SIGS, changes in modem signals are ignored by the driver. RDR_SIGS, the driver will notify upstream modules when there is a change in modem input signals via a RDR_ERROR_IND with rdr_errno equal to either RDR_LINKUP or RDR_LINKDOWN.

tp_sync

tp_idle

tp_modem_in

tp_sigtimeout

specifies the amount of time (in10ms increments) to delay before processing a modem signal interrupt (normally referred to a debounce time). This parameter applies only if the tp_modem_in parameter is set to RDR_SIGS.

tp_relaxed_data_gathering specifies that unparsed data including SOM be sent up to client application (0 - off, 1 - on). phyIf The phyIf field configures the physical interface of a CPC358. It is ignored by all other products. The supported interfaces and their respective values are: V. 11 RS530A RS530 X.21 V.35 RS449 WANSTRPROT_PHYIF_V11 or 0 WANSTRPROT _PHYIF_RS530A or 1 WANSTRPROT _PHYIF_RS530 or 2 WANSTRPROT _PHYIF_X21 or 3 WANSTRPROT _PHYIF_V35 or 4 WANSTRPROT _PHYIF_RS449 or 5

45

Chapter 4: Control Primitives

RS232 HIZ tp_error_info

WANSTRPROT _PHYIF_RS232 or 6 WANSTRPROT _PHYIF_HIZ or 7

Report protocol errors to the application by sending a RDR_ERROR_IND message with an rdr_errno of RDR_BAD_MARKBIT for mark bit errors or an rdr_errno of RDR_BAD_CRC for check group errors. Set this parameter to one to enable this feature or zero to disable.

tp_purge_committed_data specifies whether the transmit BDs will be immediately purged of data when CTS/DCD go down. This parameter should be used in conjunction with tp_data_acks and tp_noclock_to to ensure that stale data is not left on the controller when CTS/DCD go back up. The preferred data purging mechanism is to use tp_noclock_to solely. This feature applies to xSTRa based platforms only. tp_encoding Specifies the type of encoding for the link (NexusWare platforms only), which is defined by the following structure:
typedef enum _wanStrC_serRxTxEncode_t { WANSTRC_SER_RXTX_ENC_NRZ, WANSTRC_SER_RXTX_ENC_NRZ_INV, WANSTRC_SER_RXTX_ENC_NRZI_MARK, WANSTRC_SER_RXTX_ENC_NRZI_SPACE, WANSTRC_SER_RXTX_ENC_FM0, WANSTRC_SER_RXTX_ENC_FM1, WANSTRC_SER_RXTX_ENC_MANCHESTER, WNASTRC_SER_RXTX_ENC_DIFF_MANCHESTER } wanStrC_serRxTxEncode_t;

tp_idle_buf_to

This parameter determines the amount of time (in tenths of a second) allowed for transmission of an non 8-bit idle buffer when transmit data acknowledgements are enabled. This parameter applies to NexusWare based platforms only.

tp_enhanced

Specifies whether the TPS43_C variant should use the enhanced transmitter and receiver. The enhanced transmitter frames raw data into TPS43_C format for transmission (the raw data must have the final mark bit set). The enhanced receiver strips off framing bits before it passes the data to the application. Set this parameter to one to enable this feature or zero to disable.

raduga2_bind_req_t Structure Parameters


The raduga2_bind_req_t structure defines the data part of the message for Raduga-2: raduga2_primitive not used. raduga2_link identifies the DLSAP that will be bound to the connection. This parameter must have the same value as the rdr_link field in the control part of the message.

46

RDR_BIND_REQ

raduga2_baud

specifies the line speed for the connection. A value of -1 for this parameter configures the link for external clocking, meaning that the transmit clock must be supplied by an external device (such as a modem). The receive clock signal is configured as an input (supplied by the transmitting device or other external device). For a normal receive-only connection, cd_baud should always be set to -1.

raduga2_timeout_baud specifies the line speed in bits/second. For example, if the line speed is 9600 bps, raduga2_timeout_baud should be set to 9600. This value is used to calculate the time stamp for received messages. In the Toshiba radar protocol, this value is also used in conjunction with the desired time delay value (raduga2_fwd_time) to calculate how much idle padding to append to a transmitted message. raduga2_maxmesg_size specifies the number of bytes required to store the maximum length radar message in the selected data format. RDR uses this value to identify errors in received data and to format messages within the data portion of RDR_DATA_IND primitives. raduga2_maxmesg_cnt defines the maximum number of data messages that will be accumulated by the radar protocol module before they are forwarded to the radar mux. raduga2_fwd_time specifies the length of time, in increments of one hundred milliseconds, the radar protocol module waits before sending a block of received messages to the radar mux when raduga2_maxmesg_cnt has not been reached.

raduga2_dma_blocksize determines the number of 8-bit bytes to be received before the data is processed (assembled into messages and forwarded to the application). Blocks of the specified size are received by the serial device driver and passed to a radar protocol module for processing. A very small block size decreases the efficiency of the serial device driver, while a large block size increases the latency of received messages. (The time stamp on each message is always accurate, regardless of the configured block size.) raduga2_contype specifies RDR_READONLY for normal receive-only operation, RDR_WRITEONLY to transmit data, or RDR_READWRITE which allows reading and writing on the same link (QUICC platforms only). specifies the hexadecimal value of the start group. This would be the Barker Code (0x712) for Raduga-2 messages.

raduga2_sync

raduga2_check_crc at this moment, not used. raduga2_check_parity at this moment, not used.

47

Chapter 4: Control Primitives

raduga2_modem_in

specifies how the SBSI driver should handle changes in modem input signals during link operation: RDR_NO_SIGS, changes in modem signals are ignored by the driver. RDR_SIGS, the driver will notify upstream modules when there is a change in modem input signals via a RDR_ERROR_IND with rdr_errno equal to either RDR_LINKUP or RDR_LINKDOWN.

raduga2_sigtimeout specifies the amount of time (in 10ms increments) to delay before processing a modem signal interrupt (normally referred to a debounce time). This parameter applies only if the tp_modem_in parameter is set to RDR_SIGS. raduga2_do_idle specifies that the Radar Protocol should idle out the non 8-bit idle pattern defined in the raduga2_idle_pattern. If set, the protocol will construct the minimum sized buffer that will contain the non 8-bit idle pattern without padding to the end of a byte. This will be 240 bits (30 bytes) due to Raduga-2's 30-bit words. This is not applicable for links set to READONLY.

raduga2_idle_pattern user specified non 8-bit idle sequence (in lieu of the standard 8-bit idle character) for Raduga-2 when no radar data is being transmitted on the serial link. The intended idle patter for the Raduga-2 protocol is the Silence Message (0x3890800E). phyIf The phyIf field configures the physical interface of a CPC358. It is ignored by all other products. The supported interfaces and their respective values are: V. 11 RS530A RS530 X.21 V.35 RS449 RS232 HIZ WANSTRPROT_PHYIF_V11 or 0 WANSTRPROT _PHYIF_RS530A or 1 WANSTRPROT _PHYIF_RS530 or 2 WANSTRPROT _PHYIF_X21 or 3 WANSTRPROT _PHYIF_V35 or 4 WANSTRPROT _PHYIF_RS449 or 5 WANSTRPROT _PHYIF_RS232 or 6 WANSTRPROT _PHYIF_HIZ or 7

raduga2_purge_committed_data specifies whether the transmit BD's will be immediately purged of data when CTS/DCD go down. This parameter should be used in conjunction with raduga2_data_acks and raduga2_noclock_to to ensure that stale data is not left on the controller when CTS/DCD go back up. The preferred data purging mechanism is to use raduga2_noclock_to solely. This feature applies to xSTRa based platforms only.

48

RDR_BIND_REQ

raduga2_encoding

Specifies the type of encoding for the link (NexusWare platforms only), which is defined by the following structure:
typedef enum _wanStrC_serRxTxEncode_t { WANSTRC_SER_RXTX_ENC_NRZ, WANSTRC_SER_RXTX_ENC_NRZ_INV, WANSTRC_SER_RXTX_ENC_NRZI_MARK, WANSTRC_SER_RXTX_ENC_NRZI_SPACE, WANSTRC_SER_RXTX_ENC_FM0, WANSTRC_SER_RXTX_ENC_FM1, WANSTRC_SER_RXTX_ENC_MANCHESTER, WNASTRC_SER_RXTX_ENC_DIFF_MANCHESTER } wanStrC_serRxTxEncode_t;

raduga2_idle_buf_to This parameter determines the amount of time (in tenths of a second) allowed for transmission of an non 8-bit idle buffer when transmit data acknowledgements are enabled. This parameter applies to NexusWare based platforms only.

State
This message is valid in state RDR_UNBOUND.

New State
The resulting state is RDR_BIND_PENDING.

Response
When RDR successfully processes the bind request, it sends RDR_BIND_ACK to the application and the resulting state is RDR_DATAXFER. If the request is in error, RDR returns RDR_ERROR_ACK and the state reverts to RDR_UNBOUND. When the protocol is ASTERIX and modem signals are enabled in the bind request, due to ASTERIX using HDLC instead of SBSI like the rest of the Radar protocols, a special procedure is required to establish the link when the bind request is issued and the link's modem signals are down. After the bind request for ASTERIX with modem signals is issued to the controller, ASTERIX issues an OPEN_LINK to HDLC. If HDLC detects an error in the bind parameters, a response is issued to ASTERIX which returns one of the listed failures except RDR_START_FAIL_NO_SIGS. If HDLC returns a successful response, ASTERIX then issues a START_LINK. If the link is up, a RDR_BIND_ACK is immediately returned. If the link is down, the bind response is delayed until either the link becomes up, in which case the RDR_BIND_ACK is returned, or 30 seconds elapses and a bind RDR_ERROR_ACK with a rdr_errno value of RDR_START_FAIL_NO_SIGS is returned. The link can either be closed or

49

Chapter 4: Control Primitives

the RDR_REISSUE_START primitive can be issued in an attempt to establish the link. The response to this primitive is either the RDR_BIND_ACK if the link is up or becomes up before 30 seconds elapses, or a bind RDR_ERROR_ACK, RDR_START_FAIL_NO_SIGS if the link is still down. As long as the response is a bind RDR_ERROR_ACK, RDR_START_FAIL_NO_SIGS, the RDR_REISSUE_START primitive can be issued.

Reasons for Failure


RDR_DLSAP_IN_USE RDR_INVALIDPORT RDR_NOSUCHPROTOCOL RDR_INVALID_BIND_PARAMS RDR_NOFREEUSCB RDR_START_FAIL_NO_SIGS The requested DLSAP is already bound to another connection. The specified DLSAP is invalid (out of range). The rdr_protocol string is invalid. Either the control part or data part Bind parameters structure is not of valid format. RDR cannot obtain the system resources necessary to complete the bind request. The protocol is ASTERIX and no modem signals were detected on the line for 30 seconds.

50

RDR_BIND_ACK

RDR_BIND_ACK
This message is sent by RDR in response to a RDR_BIND_REQ to report the successful bind of a DLSAP to a connection. Once this response has been received, the station is in data transfer mode.

Message Format
The control part of this message is defined by the following structure: typedef struct { bit32 rdr_primitive; bit32 rdr_link; } rdr_bind_ack_t; There is no data part.

Parameters
rdr_primitive rdr_link conveys RDR_BIND_ACK. identifies the DLSAP that was bound.

State
This message is valid in state RDR_BIND_PENDING.

New State
The resulting state is RDR_DATAXFER.

51

Chapter 4: Control Primitives

RDR_UNBIND_REQ
This message is sent by an application to request RDR to unbind the DLSAP that was previously bound to the connection with a RDR_BIND_REQ.

Message Format
The control part of the message is defined by the following structure: typedef struct { bit32 rdr_primitive; bit32 rdr_link; } rdr_primitive; There is no data part.

Parameters
rdr_primitive rdr_link conveys RDR_UNBIND_REQ. identifies the DLSAP.

State
This message is valid in state RDR_DATAXFER.

New State
The resulting state is RDR_UNBIND_PENDING.

Response
In response, RDR sends RDR_OK_ACK to the application, resulting in state RDR_UNBOUND. If the request is in error, RDR returns RDR_ERROR_ACK and the state is unchanged.

Reasons for Failure


RDR_NOTINIT RDR_INVALIDPORT The specified DLSAP is not currently bound to the connection. The specified DLSAP is invalid (out of range).

52

RDR_OK_ACK

RDR_OK_ACK
This message acknowledges to the application that a previously issued request primitive was processed successfully. It is only initiated for those primitives that require a positive acknowledgement.

Message Format
The control part of the message is defined by the following structure: typedef struct { bit32 rdr_primitive; bit32 rdr_correct_primitive; bit32 rdr_modifier; } rdr_ok_ack_t; There is no data part.

Parameters
rdr_primitive conveys RDR_OK_ACK. rdr_correct_primitive identifies the successfully received primitive that is being acknowledged. rdr_modifier identifies the DLSAP.

State
This message is valid from any of several states, in response to one of the following message types:
RDR_ATTACH_REQ RDR_DETACH_REQ RDR_UNBIND_REQ RDR_CLEAR_TICK

New State
The resulting state depends on the state from which the primitive was issued.

53

Chapter 4: Control Primitives

RDR_DATA_ACK
This message acknowledges to the application that a data request primitive was processed successfully.

Message Format
The control part of the message is defined by the following structure: typedef struct { bit32 bit32 bit32 struct utimeval wanStrPro_timeStatus_t } rdr_data_ack_t;

rdr_primitive; rdr_link; rdr_timestamp; rdr_sntp_timestamp; rdr_timeStatus;

If this message is due to a Data Acknowledgement (positive or negative) and Data Acknowledgements were setup to include the requested message (see the parameter rdr_data_acks of the Radar Protocol Bind request RDR_BIND_REQ on page 30), the data part will be that message. Else, there is no data part. This feature only applies to the NexusWare base Protocol controllers.

Parameters
rdr_primitive rdr_link rdr_timestamp conveys RDR_DATA_ACK. identifies the DLSAP. contains the time stamp (tick count), recorded at the time the message block was received.

rdr_sntp_timestamp contains the optional SNTP timestamp applied to received message blocks. This field only applies to certain models of PTI LAN-based servers. The timestamp is reported in a structure that consists of two fields: the number of seconds and the number of microseconds of Universal Coordinated Time (UTC). rdr_timeStatus specifies the external timestamp status if it is being used (see the parameter rdr_options1 in the RDR_BIND_REQ on page 30). This parameter is an enumeration and is treated as a bit field where more than one feature can be or'd together. This feature only applies to the NexusWare base Protocol controllers. The bit definitions are:
WANSTRPROT_TS_CLOCK_NOT_LOCKED (0x00000001)

indicates that the external clock's external synchronization signal is either unstable or missing.
WANSTRPROT_TS_CLOCK_NOT_SYNCED (0x00000002)

54

RDR_DATA_ACK

indicates that the external clock has not yet synchronized to the external synchronization signal.
WANSTRPROT_TS_CLOCK_INACCURATE (0x00000004)

indicates that the external clocks internal oscillator is not accurate and could indicate a hardware problem.

State
This message is valid in response to one of the following message types:
CD_DATA_REQ AS_DATA_REQ TC_DATA_REQ TP_DATA_REQ

New State
The resulting state depends on the state from which the primitive was issued.

55

Chapter 4: Control Primitives

RDR_ERROR_ACK
This message informs the application that the operation requested by a previously issued primitive failed.

Message Format
The control part of the message is defined by the following structure: typedef struct { bit32 bit32 bit32 bit32 bit32 struct utimeval wanStrPro_timeStatus_t } rdr_error_ack_t;

rdr_primitive; rdr_error_primitive; rdr_errno; rdr_modifier; rdr_timestamp; rdr_sntp_timestamp; rdr_timeStatus;

If this message is due to a Data Acknowledgement (positive or negative) and Data Acknowledgements were setup to include the requested message (see the parameter rdr_data_acks of the Radar Protocol Bind request RDR_BIND_REQ on page 30), the data part will be that message. Else, there is no data part. This feature only applies to the NexusWare base Protocol controllers.

Parameters
rdr_primitive conveys RDR_ERROR_ACK. rdr_error_primitive identifies the primitive in error. rdr_errno rdr_modifier rdr_timestamp conveys the DLPI error code associated with the failure. See the individual primitive for the error codes that are applicable. identifies the DLSAP. contains the time stamp (tick count), recorded at the time the message block was received.

rdr_sntp_timestamp contains the optional SNTP timestamp applied to received message blocks. This field only applies to certain models of PTI LAN-based servers. The timestamp is reported in a structure that consists of two fields: the number of seconds and the number of microseconds of Universal Coordinated Time (UTC). rdr_timeStatus specifies the external timestamp status if it is being used (see the parameter rdr_options1 in the RDR_BIND_REQ on page 30). This parameter is an enumeration and is treated as a bit field where more than one feature can be or'd together. This feature only applies to the NexusWare base Protocol controllers. The bit definitions are:

56

RDR_ERROR_ACK

WANSTRPROT_TS_CLOCK_NOT_LOCKED (0x00000001)

indicates that the external clock's external synchronization signal is either unstable or missing.
WANSTRPROT_TS_CLOCK_NOT_SYNCED (0x00000002)

indicates that the external clock has not yet synchronized to the external synchronization signal.
WANSTRPROT_TS_CLOCK_INACCURATE (0x00000004)

indicates that the external clocks internal oscillator is not accurate and could indicate a hardware problem.

State
The message is valid in every state where an acknowledgement or confirmation of a previous request or response is pending.

New State
The resulting state is that from which the acknowledged primitive was generated.

57

Chapter 4: Control Primitives

RDR_REISSUE_START
This message is sent after the response to a bind request is a bind RDR_ERROR_ACK with an rdr_errno value of RDR_START_FAIL_NO_SIGS and requests that another attempt to start the link be made.

Message Format
The control part of the message is defined by the following structure: typedef struct { bit32 rdr_primitive; bit32 rdr_link; } rdr_primitive; There is no data part.

Parameters
rdr_primitive rdr_link conveys RDR_BIND_ACK. identifies the DLSAP that was bound.

State
This message is valid in state RDR_BIND_PENDING.

New State
The resulting state is unchanged.

Response
If the link is started successfully, a RDR_BIND_ACK is returned. Otherwise, an RDR_ERROR_ACK is returned.

Reasons for Failure


RDR_START_FAIL_NO_SIGS The protocol is ASTERIX and no modem signals were detected on the line for 30 seconds.

58

RDR_ERROR_IND

RDR_ERROR_IND
This message informs the application that the serial link associated with the connection is not operating correctly. After sending this primitive, RDR continues to monitor the serial link, and automatically returns to normal operation when valid data is received.

Message Format
The control part of this message is defined by the following structure: typedef struct { bit32 rdr_primitive; bit32 rdr_link; bit32 rdr_errno; } rdr_error_ind_t; There is no data part.

Parameters
rdr_primitive rdr_link rdr_errno conveys RDR_ERROR_IND. identifies the DLSAP. identifies the error condition. The following error codes are possible: CD_EMSGSIZE More than the configured maximum number of bytes per message were received without detecting an idle character to terminate the message. This error can only occur on a link configured for CD-2 (FPS 117), Marconi 10-Bit, Modified Eurocontrol, General 18-Bit or NEC Radar Extractor. The receiver lost synchronization on the serial link. (When this error occurs, RDR automatically attempts to reestablish synchronization.) This error can only occur on a link configured for CD2 (FPS 117), Marconi 10-Bit, Modified Eurocontrol or General 18-Bit. More than the configured maximum number of bytes per message were received without detecting an ETX character to terminate the message. This error can only occur on a link configured for Thompson-CSF, Thompson-TVT2 or Toshiba.

CD_ECOMM

TC_EMSGSIZE

RADUGA2_EMSGSIZE The current Raduga-2 message that is being received has more than 5 30-bit words defined as its length.

59

Chapter 4: Control Primitives

AS_LINKDOWN AS_LINKUP RDR_CTS_UP

The receiver has lost link (connection) on the serial link. The receiver has a link condition (connection) on the serial link. Clear to Send Changes state from disabled to enabled. This error can only occur when either the cd_modem_in, tp_modem_in, or tc_modem _in parameter from the corresponding bind structure is set to RDR_SIGS. Clear to Send changes state from enabled to disabled. This error can only occur when either the cd_modem_in, tp_modem_in, or tc_modem _in parameter from the corresponding bind structure is set to RDR_SIGS. indicates a protocol message failed a mark bit test and will be discarded. Setting the tp_error_info parameter enables this message.

RDR_CTS_DOWN

RDR_BAD_MARKBIT

RDR_BAD_CRC

indicates a protocol message failed a crc test and will be discarded. Setting the tp_error_info parameter enables this message. Data Carrier Detect changes state from disabled to enabled. This error can only occur when either the cd_modem_in, tp_modem_in, tc_modem_in or raduga2_modem_in parameter from the corresponding bind structure is set to RDR_SIGS. Data Carrier Detect changes state from enabled to disabled. This error can only occur when either the cd_modem_in, tp_modem_in, tc_modem_in or raduga2_modem_in parameter from the corresponding bind structure is set to RDR_SIGS.

RDR_DCD_UP

RDR_DCD_DOWN

State
This message is valid in state RDR_DATAXFER.

New State
The resulting state is unchanged.

60

RDR_CLEAR_TICK

RDR_CLEAR_TICK
An application sends this message to RDR to clear the system tick counter, which is used to time stamp received messages. Since the system maintains a single, global tick counter for each communication controller, this primitive affects the time stamp for subsequent received messages on all serial links of a given controller. Note: This primitive applies to xSTRa-based platforms only.

Message Format
The control part of the message is defined by the following structure: typedef struct { bit32 rdr_primitive; bit32 rdr_link; } rdr_primitive; There is no data part.

Parameters
rdr_primitive rdr_link conveys RDR_CLEAR_TICK. identifies the DLSAP.

State
This message is valid in any state.

New State
The resulting state is unchanged.

Response
RDR responds to this request with RDR_OK_ACK. If the request is in error, RDR returns RDR_ERROR_ACK instead.

Reasons for Failure


RDR_INVALIDPORT The specified DLSAP is invalid (out of range).

61

Chapter 4: Control Primitives

CD_STATISTICS_REQ
An application sends this message to RDR to request data transfer statistics for a serial link configured for the CD-2 (FPS 117), Marconi 10-Bit, Modified Eurocontrol, General 18 bit or NEC Radar Extractor radar data format.

Message Format
The control part of the message is defined by the following structure: typedef struct { bit32 rdr_primitive; bit32 rdr_link; } rdr_primitive; There is no data part.

Parameters
rdr_primitive rdr_link conveys CD_STATISTICS_REQ. identifies the serial link (DLSAP) for which statistical information is requested.

State
This message is valid in state RDR_DATAXFER.

New State
The resulting state is unchanged.

Response
RDR responds to this request with CD_STATISTICS_ACK. If the request is in error, RDR returns RDR_ERROR_ACK instead.

Reasons for Failure


RDR_INVALIDPORT The specified DLSAP is invalid (out of range).

62

CD_STATISTICS_ACK

CD_STATISTICS_ACK
RDR sends this message in response to CD_STATISTICS_REQ.

Message Format
The control part of the message is defined by the following structure: typedef struct { bit32 rdr_primitive; bit32 rdr_link; } rdr_primitive; See rdr_primitive Structure Parameters, on page 63 for a description of each parameter. The statistics information is contained in the data part of the message, which is defined by the following structure: typedef struct { bit32 cd_recv_msgs; bit32 cd_recv_2big; bit32 cd_sync_lost; bit32 cd_recv_orun; bit32 cd_no_timers; bit32 cd_no_buffers; bit32 cd_bad_mtype; bit32 cd_recv_borun; bit32 cd_xmit_msgs; bit32 cd_no_clocks; bit32 cd_data_acks; } cd_statistics_t; See cd_statistics_t Structure Parameters, on page 64 for a description of each parameter.

Parameters
rdr_primitive Structure Parameters
In the rdr_primitive structure: rdr_primitive rdr_link conveys CD_STATISTICS_ACK. identifies the DLSAP to which the statistical information applies.

63

Chapter 4: Control Primitives

cd_statistics_t Structure Parameters


The cd_statistics_t structure contains event counts for the connection associated with the specified serial link, as follows: cd_recv_msgs cd_recv_2big cd_sync_lost cd_recv_orun cd_no_timers cd_no_buffers cd_bad_mtype cd_recv_borun cd_xmit_msgs cd_no_clocks cd_data_acks total number of received messages since the connection was established. number of times the maximum message size configured for the connection was exceeded. number of times synchronization on the serial link was lost. number of receive overruns. number of times the data-forwarding timer could not be initiated due to a shortage of system resources. number of times the radar protocol module was required to retry an attempt to obtain a data buffer for received data. number of unrecognized message types (non-protocol messages) received from the connected application. number of received data buffers overwritten due to lack of memory resources. total number of messages transmitted since the connection was established (diagnostic connection only). number of times the serial device driver failed to forward any data (due to lack of clocks). total number of data acknowledgements received in response to a DATA_REQ primitive.

State
This message is valid in state RDR_DATAXFER.

New State
The resulting state is unchanged.

64

AS_STATISTICS_REQ

AS_STATISTICS_REQ
An application sends this message to RDR to request data transfer statistics for a serial link configured for the ASTERIX radar data format.

Message Format
The control part of the message is defined by the following structure: typedef struct { bit32 rdr_primitive; bit32 rdr_link; } rdr_primitive; There is no data part.

Parameters
rdr_primitive rdr_link conveys AS_STATISTICS_REQ. identifies the serial link (DLSAP) for which statistical information is requested.

State
This message is valid in state RDR_DATAXFER.

New State
The resulting state is unchanged.

Response
RDR responds to this request with AS_STATISTICS_ACK. If the request is in error, RDR returns RDR_ERROR_ACK instead.

Reasons for Failure


RDR_INVALIDPORT The specified DLSAP is invalid (out of range).

65

Chapter 4: Control Primitives

AS_STATISTICS_ACK
RDR sends this message in response to AS_STATISTICS_REQ.

Message Format
The control part of the message is defined by the following structure: typedef struct { bit32 rdr_primitive; bit32 rdr_link; } rdr_primitive; See rdr_primitive Structure Parameters, on page 66 for a description of each parameter. The statistics information is contained in the data part of the message, which is defined by the following structure: typedef struct { bit32 as_xgood; bit32 as_rgood; bit32 as_xunder; bit32 as_rover; bit32 as_rtoo; bit32 as_rcrc; bit32 as_rabt; bit32 as_no_clocks; bit32 as_data_acks; bit32 as_corrupt_msgs; } as_statistics_t; See as_statistics_t Structure Parameters, on page 66 for a description of each parameter.

Parameters
rdr_primitive Structure Parameters
In the rdr_primitive structure: rdr_primitive rdr_link conveys AS_STATISTICS_ACK. identifies the DLSAP to which the statistical information applies.

as_statistics_t Structure Parameters


The as_statistics_t structure contains event counts for the connection associated with the specified serial link, as follows: as_xgood total number of messages transmitted since the connection was established.

66

AS_STATISTICS_ACK

as_rgood as_xunder as_rover as_rtoo as_rcrc as_rabt as_no_clocks as_data_acks as_corrupt_msgs

total number of received messages since the connection was established. number of transmit underruns. number of receive overruns. number of times the maximum message size configured for the connection was exceeded. number of CRC (frame check sequence) errors. number of aborted frames. number of times the serial device driver failed to forward any data (due to lack of clocks). total number of data acknowledgements receieved in response to a DATA_REQ primitive. number of corrupt messages transmitted. This occurs if the message was not completely transmitted due to an error.

State
This message is valid in state RDR_DATAXFER.

New State
The resulting state is unchanged.

67

Chapter 4: Control Primitives

TC_STATISTICS_REQ
An application sends this message to RDR to request data transfer statistics for a serial link configured for Thompson-CSF, Thompson-TVT2 or Toshiba radar data format.

Message Format
The control part of the message is defined by the following structure: typedef struct { bit32 rdr_primitive; bit32 rdr_link; } rdr_primitive; There is no data part.

Parameters
rdr_primitive rdr_link conveys TC_STATISTICS_REQ. identifies the serial link (DLSAP) for which statistical information is requested.

State
This message is valid in state RDR_DATAXFER.

New State
The resulting state is unchanged.

Response
RDR responds to this request with TC_STATISTICS_ACK. If the request is in error, RDR returns RDR_ERROR_ACK instead.

68

TC_STATISTICS_ACK

TC_STATISTICS_ACK
RDR sends this message in response to TC_STATISTICS_ACK.

Message Format
The control part of the message is defined by the following structure: typedef struct { bit32 rdr_primitive; bit32 rdr_link; } rdr_primitive; See rdr_primitive Structure Parameters, on page 69 for a description of each parameter. The statistics information is contained in the data part of the message, which is defined by the following structure: typedef struct { bit32 tc_recv_msgs; bit32 tc_xmit_msgs; bit32 tc_recv_2big; bit32 tc_xmit_2big; bit32 tc_recv_orun; bit32 tc_no_timers; bit32 tc_no_buffers; bit32 tc_bad_bcc; bit32 tc_bad_mtype; bit32 tc_recv_borun; bit32 tc_no_clocks; bit32 tc_data_acks; } tc_statistics_t; See tc_statistics_t Structure Parameters, on page 69 for a description of each parameter.

Parameters
rdr_primitive Structure Parameters
In the rdr_primitive structure: rdr_primitive rdr_link conveys TC_STATISTICS_REQ. identifies the DLSAP to which the statistical information applies.

tc_statistics_t Structure Parameters


The tc_statistics_t structure contains event counts for the connection associated with the specified serial link, as follows:

69

Chapter 4: Control Primitives

tc_recv_msgs tc_xmit_msgs tc_recv_2big tc_xmit_2big tc_recv_orun tc_no_timers tc_no_buffers tc_bad_bcc tc_bad_mtype tc_recv_borun tc_no_clocks tc_data_acks

total number of received messages since the connection was established. total number of messages transmitted since the connection was established. number of times the maximum receive message size configured for the connection was exceeded. number of times the maximum transmit message size configured for the connection was exceeded. number of receive overruns. number of times the data-forwarding timer could not be initiated due to a shortage of system resources. number of times received data was discarded because memory was not available. number of messages discarded due to block check errors. number of unrecognized message types (non-protocol messages) received from the connected application. number of received data buffers overwritten due to lack of memory resources number of times the serial device driver failed to forward any data (due to lack of clocks). total number of data acknowledgements received in response to DATA_REQ primitive.

State
This message is valid in any state.

New State
The resulting state is unchanged.

70

TP_STATISTICS_REQ

TP_STATISTICS_REQ
An application sends this message to RDR to request data transfer statistics for a serial link configured for the TPS-43 or TPS-75 radar data formats.

Message Format
The control part of the message is defined by the following structure: typedef struct { bit32 rdr_primitive; bit32 rdr_link; } rdr_primitive; There is no data part.

Parameters
rdr_primitive rdr_link conveys TP_STATISTICS_REQ. identifies the serial link (DLSAP) for which statistical information is requested.

State
This message is valid in state RDR_DATAXFER.

New State
The resulting state is unchanged.

Response
RDR responds to this request with TP_STATISTICS_ACK. If the request is in error, RDR returns RDR_ERROR_ACK instead.

71

Chapter 4: Control Primitives

TP_STATISTICS_ACK
RDR sends this message in response to TP_STATISTICS_ACK.

Message Format
The control part of the message is defined by the following structure: typedef struct { bit32 rdr_primitive; bit32 rdr_link; } rdr_primitive; See rdr_primitive Structure Parameters, on page 72 for a description of each parameter. The statistics information is contained in the data part of the message, which is defined by the following structure: typedef struct { bit32 tp_recv_msgs; bit32 tp_xmit_msgs; bit32 tp_recv_2big; bit32 tp_xmit_2big; bit32 tp_recv_orun; bit32 tp_no_timers; bit32 tp_no_buffers; bit32 tp_bad_mtype; bit32 tp_recv_borun; bit32 tp_bad_parity; bit32 tp_xmt_rjct; bit32 tp_no_clocks; bit32 tp_data_acks; bit32 tp_bad_mbit } tp_statistics_t; See tp_statistics_t Structure Parameters, on page 73 for a description of each parameter.

Parameters
rdr_primitive Structure Parameters
In the rdr_primitive structure: rdr_primitive rdr_link conveys TP_STATISTICS_REQ. identifies the DLSAP to which the statistical information applies.

72

TP_STATISTICS_ACK

tp_statistics_t Structure Parameters


The tp_statistics_t structure contains event counts for the connection associated with the specified serial link, as follows: tp_recv_msgs tp_xmit_msgs tp_recv_2big tp_xmit_2big tp_recv_orun tp_no_timers tp_no_buffers tp_bad_mtype tp_recv_borun tp_bad_parity tp_xmt_rjct tp_no_clocks tp_data_acks tp_bad_mbit total number of received messages since the connection was established. total number of messages transmitted since the connection was established. number of times the maximum receive message size configured for the connection was exceeded. number of times the maximum transmit message size configured for the connection was exceeded. number of receive overruns. number of times the data-forwarding timer could not be initiated due to a shortage of system resources. number of times received data was discarded because memory was not available. number of unrecognized message types (non-protocol messages) received from the connected application. number of received data buffers overwritten due to lack of memory resources. number of received messages discarded due to parity errors or mark bit errors (if TPS43_B, TPS43_C, TPS43_D or TPS-75). number of transmitted messages discarded due to the message size not being an even multiple of the data size. number of times the serial device driver failed to forward any data (due to lack of clocks). total number of data acknowledgements received in response to a DATA_REQ primitive. number of transmit messages discarded due to the final mark bit not being set.

State
This message is valid in any state.

New State
The resulting state is unchanged.

73

Chapter 4: Control Primitives

RADUGA2_STATISTICS_REQ
An application sends this message to RDR to request data transfer statistics for a serial link configured for the Raduga-2 radar data formats.

Message Format
The control part of the message is defined by the following structure: typedef struct { bit32 rdr_primitive; bit32 rdr_link; } rdr_primitive; There is no data part.

Parameters
rdr_primitive rdr_link conveys RADUGA2_STATISTICS_REQ. identifies the serial link (DLSAP) for which statistical information is requested.

State
This message is valid in state RDR_DATAXFER.

New State
The resulting state is unchanged.

Response
RDR responds to this request with RADUGA2_STATISTICS_ACK. If the request is in error, RDR returns RDR_ERROR_ACK instead.

74

RADUGA2_STATISTICS_ACK

RADUGA2_STATISTICS_ACK
RDR sends this message in response to RADUGA2_STATISTICS_ACK.

Message Format
The control part of the message is defined by the following structure: typedef struct { bit32 rdr_primitive; bit32 rdr_link; } rdr_primitive; See rdr_primitive Structure Parameters, on page 75 for a description of each parameter. The statistics information is contained in the data part of the message, which is defined by the following structure: typedef struct { bit32 raduga2_recv_msgs; bit32 raduga2_xmit_msgs; bit32 raduga2_recv_2big; bit32 raduga2_xmit_2big; bit32 raduga2_recv_orun; bit32 raduga2_no_timers; bit32 raduga2_no_buffers; bit32 raduga2_bad_mtype; bit32 raduga2_recv_borun; bit32 raduga2_no_clocks; bit32 raduga2_data_acks; bit32 raduga2_num_parity; bit32 raduga2_bad_msg_lngth; bit32 raduga2_num_crc; bit32 raduga2_bad_mark_bit; bit32 raduga2_xmit_rjct; } raduga2_statistics_t;

/* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /*

Total messages received Total xmt messages Recv messages too big Xmit message too big Receive overruns Forward timer failures Buffer alloc failures Unknown STREAMS type Receive buffer overruns No data due to no clocks # Data Acks sent up stream # Message parity errors # Message Length errors # CRC (Control Pattern) errors # Mark bit errors # Transmit Data Req rejected.

*/ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */

See raduga2_statistics_t Structure Parameters, on page 76 for a description of each parameter.

Parameters
rdr_primitive Structure Parameters
In the rdr_primitive structure: rdr_primitive conveys RADUGA2_STATISTICS_REQ.

75

Chapter 4: Control Primitives

rdr_link

identifies the DLSAP to which the statistical information applies.

raduga2_statistics_t Structure Parameters


The raduga2_statistics_t structure contains event counts for the connection associated with the specified serial link, as follows: raduga2_recv_msgs total number of received messages since the connection was established. raduga2_xmit_msgs total number of messages transmitted since the connection was established. raduga2_recv_2big number of times the maximum receive message size configured for the connection was exceeded. raduga2_xmit_2big number of times the maximum transmit message size configured for the connection was exceeded. raduga2_recv_orun number of receive overruns. raduga2_no_timers number of times the data-forwarding timer could not be initiated due to a shortage of system resources. raduga2_no_buffers number of times received data was discarded because memory was not available. raduga2_bad_mtype number of unrecognized message types (non-protocol messages) received from the connected application. raduga2_recv_borun number of received data buffers overwritten due to lack of memory resources. raduga2_no_clocks number of times the serial device driver failed to forward any data (due to lack of clocks). raduga2_data_acks total number of data acknowledgements received in response to a DATA_REQ primitive. raduga2_num_parity number of received messages discarded due to parity errors. raduga2_bad_msg_lngth number of received messages discarded due to invalid message length. raduga2_num_crc number of received messages discarded due CRC (Control Pattern) errors.

raduga2_bad_mark_bit number of received messages discarded due to mark bit errors raduga2_xmt_rjct currently not used.

76

RADUGA2_STATISTICS_ACK

State
This message is valid in any state.

New State
The resulting state is unchanged.

77

Chapter 4: Control Primitives

CD_DATA_REQ
An application uses this primitive to send a block of data to RDR for transmission on a serial link configured for the CD-2 (FPS 117), Marconi 10-Bit, Modified Eurocontrol, General 18-Bit or NEC Radar Extractor radar data format. The link must be configured in diagnostic mode. RDR guarantees to transmit each block in the same order as received from the application. When the data supplied with a CD_DATA_REQ has been completely transmitted and another CD_DATA_REQ is available for processing, RDR will begin transmitting the next block of data without interruption. If no new data is available for transmission and the protocol is not the NEC Radar Extractor, the serial line will transmit the non 8-bit idle sequence specified by the bind parameters cd_idle_pattern and if the bind parameter cd_do_idle has been set.

Message Format
The control part of the message is defined by the following structure: typedef struct { bit32 cd_primitive; bit32 cd_link; bit32 cd_noclock_to; } cd_data_req_t; The data part of the message contains the block of data to be transmitted.

Parameters
cd_primitive cd_link cd_noclock_to conveys CD_DATA_REQ. identifies the serial link (DLSAP) on which the block of data is to be transmitted. applies only if acknowledgements are configured for the link (see the parameter rdr_data_acks in the RDR_BIND_REQ on page 30 primitive.) This parameter determines the amount of time (in tenths of a second) allowed for transmission of the message. If the message is successfully transmitted prior to expiration of the specified time, the application will receive a RDR_DATA_ACK confirming transmission. If the message is not successfully transmitted before this time expires, the transmission is aborted, and a RDR_ERROR_ACK is returned with the rdr_errno field set to RDR_DATA_TIMEOUT. If this parameter is zero, this function is disabled.

78

CD_DATA_REQ

CD-2 (FPS 117) Data Format


The data, in the data part of the message, can be formatted as a packed or an unpacked bit stream, depending on the setting of the cd_xmt_unpackmesg parameter. In the packed format, the first two bytes of data contain the first 13-bit word and three bits of the second word. The most-significant bit of the first word is in the most significant bit of the first byte. The three leastsignificant bits of the second byte contain the three most-significant bits of the second word, and so on. On the serial line, each 13-bit word is transmitted most-significant bit first. The total number of data bytes must be calculated so that the block ends on a 13-bit word boundary if the cd_xmt_idles parameter is not set. That is, the last data byte must contain the low-order eight bits of a 13-bit word. This is not necessary if the cd_xmt_idles parameter is set. Packed CD-2 data is shown in the diagram below, where each 13-bit word is shown as a string of alphabetic characters, with the most-significant bit of the word in upper case. Byte 1
Aaaaaaaa

Byte 2
aaaaaBbb

Byte 3
bbbbbbbb

Byte 4
bbCccccc

In the unpacked format, the message data is contained in an array of chars. Each pair of chars will contain one message word. The five most significant bits of each message word will be contained in the five least significant bits of the first char. The other bits of the first char are not used. The 8 least significant bits of each message word are contained in the second char. If configured as unpacked, the CD-2 protocol will convert the data to a packed bit stream before being transmitted. On the serial line, each 13-bit word is transmitted most-significant bit first. The total number of data bytes (that is, after the conversion to packed data) must be calculated so that the block ends on a 13-bit word boundary if the cd_xmt_idles parameter is not set. That is, the last data byte must contain the low-order eight bits of a 13-bit word. This is not necessary if the cd_xmt_idles parameter is set. Unpacked CD-2 data is shown in the diagram below, where each 13-bit word is shown as a string of alphabetic characters, with the mostsignificant bit of the word in upper case. The zero value indicates unused. Byte 1
000Aaaaa

Byte 2
aaaaaaaa

Byte 3
000Bbbbb

Byte 4
bbbbbbbb

Idle words will be included between messages if the cd_xmt_idles parameter is set. If the cd_xmt_idles parameter is not set, it is assumed that each radar message within the data is separated by at least one 13-bit idle character, with at least one idle character following the last message in the block.

Marconi 10-Bit Data Format


The data, in the data part of the message, can be formatted as a packed or an unpacked bit stream, depending on the setting of the cd_xmt_unpackmesg parameter. In the packed format, the first two bytes of data contain the first 10-bit word and six bits of the second word. The least-significant bit of the first word is in the most significant bit of the first byte. The six leastsignificant bits of the second byte contain the six least-significant bits of the second word, and so on.

79

Chapter 4: Control Primitives

On the serial line, each 10-bit word is transmitted least-significant bit first. The total number of data bytes must be calculated so that the block ends on a 10-bit word boundary if the cd_xmt_idles parameter is not set. That is, the last data byte must contain the high-order eight bits of a 10-bit word. This is not necessary if the cd_xmt_idles parameter is set. Packed Marconi data is shown in the diagram below, where each 10-bit word is shown as a string of alphabetic characters, with the most-significant bit of the word in upper case. Byte 1
aaaaaaaa

Byte 2
aAbbbbbb

Byte 3
bbbBcccc

Byte 4
cccccCdd

In the unpacked format, the message data is contained in an array of chars. Each pair of chars will contain one message word. The two least significant bits of each message word will be contained in the two least significant bits of the first char. The other bits of the first char are not used. The 8 most significant bits of each message word are contained in the second char. If configured as unpacked, the Marconi protocol will convert the data to a packed bit stream before being transmitted. On the serial line, each 10-bit word is transmitted least-significant bit first. The total number of data bytes (that is, after the conversion to packed data) must be calculated so that the block ends on a 10-bit word boundary if the cd_xmt_idles parameter is not set. That is, the last data byte must contain the high-order eight bits of a 10-bit word. This is not necessary if the cd_xmt_idles parameter is set. Unpacked Marconi data is shown in the diagram below, where each 10-bit word is shown as a string of alphabetic characters, with the most-significant bit of the word in upper case. The zero value indicates unused. Byte 1
000000aa

Byte 2
aaaaaaaA

Byte 3
000000bb

Byte 4
bbbbbbbB

Idle words will be included between messages if the cd_xmt_idles parameter is set as well as STX and ETX at the start and stop of each message. If the cd_xmt_idles parameter is not set, it is assumed that each radar message within the data is separated by at least one 10-bit idle character, with at least one idle character following the last message in the block and each message is framed with STX and ETX.

Modified Eurocontrol and General 18-Bit Data Format


The data, in the data part of the message, can be formatted as a packed or an unpacked bit stream, depending on the setting of the cd_xmt_unpackmesg parameter. In the packed format, the first three bytes of data contain the first 18-bit word and six bits of the second word. The most-significant bit of the first word is in the most significant bit of the first byte. The six leastsignificant bits of the third byte contain the six most-significant bits of the second word, and so on.

80

CD_DATA_REQ

On the serial line, each 18-bit word is transmitted most-significant bit first. The total number of data bytes must be calculated so that the block ends on a 18-bit word boundary if the cd_xmt_idles parameter is not set. That is, the last data byte must contain the low-order eight bits of a 18-bit word. This is not necessary if the cd_xmt_idles parameter is set. Packed Modified Eurocontrol and General 18-bit data is shown in the diagram below, where each 18-bit word is shown as a string of alphabetic characters, with the most-significant bit of the word in upper case. Byte 1
Aaaaaaaa

Byte 2
aaaaaaaa

Byte 3
aaBbbbbb

Byte 4
bbbbbbbb

Byte5
bbbbCccc

In the unpacked format, the message data is contained in an array of chars. Four chars will contain one message word. The two most significant bits of each message word will be contained in the two least significant bits of the second char. The other bits of the first and second char are not used. The 8 least significant bits of each message word are contained in the fourth char. If configured as unpacked, the Modified Eurocontrol and General 18-bit protocols will convert the data to a packed bit stream before being transmitted. On the serial line, each 18-bit word is transmitted most-significant bit first. The total number of data bytes (that is, after the conversion to packed data) must be calculated so that the block ends on a 18-bit word boundary if the cd_xmt_idles parameter is not set. That is, the last data byte must contain the low-order eight bits of a 18-bit word. This is not necessary if the cd_xmt_idles parameter is set. Unpacked Modified Eurocontrol and General 18-bit data is shown in the diagram below, where an 18-bit word is shown as a string of alphabetic characters, with the most-significant bit of the word in upper case. The zero value indicates unused. Byte 1
00000000

Byte 2
000000Aa

Byte 3
aaaaaaaa

Byte 4
aaaaaaaa

Idle words will be included between messages if the cd_xmt_idles parameter is set. If the cd_xmt_idles parameter is not set, it is assumed that each radar message within the data is separated by at least one 18-bit idle character, with at least one idle character following the last message in the block.

NEC Radar Extractor Data Format


The data, in the data part in the message, must be completely formatted as a NEC Radar Extractor packet. The first bit of the first byte of the data must have a value of 1 to signify Start of Message. The last byte of the data packet must be the value 0x00 to signify End of Message. Byte 1
1aaaaaaa

Byte 2
Bbbbbbbb

Byte 3
Cccccccc ...

Byte N
00000000

State
This message is valid in state RDR_DATAXFER.

81

Chapter 4: Control Primitives

New State
The resulting state is unchanged.

Response
There is no response unless data acknowledgements are enabled, in which case RDR returns RDR_DATA_ACK or the request fails, in which case RDR returns RDR_ERROR_ACK.

Reasons for Failure


ENOLINK EACCESS RDR_DATA_TIMEDOUT RDR_BAD_DATA_FORMAT RDR_BAD_DATA_BLOCK No DLSAP is bound to the connection. The connection is not configured for diagnostic mode. Failed to transmit message before timeout value. The control structure is not of valid format. The data part of the request does not exist.

AS_DATA_REQ
An application uses this primitive to send a block of data to RDR for transmission on a serial link configured for the ASTERIX radar data format. The data supplied will be sent as a single HDLC frame. The frame must be completely formatted by the sending application. RDR adds only the opening and closing flags and appends the two-byte CRC. RDR guarantees to transmit each block in the same order as received from the application. The serial line idles flags (0x7E) between frames.

Message Format
The control part of the message is defined by the following structure: typedef struct { bit32 as_primitive; bit32 as_link; bit32 as_noclock_to; } as_data_req_t; The data part of the message contains the block of data to be transmitted as an HDLC frame.

Parameters
as_primitive as_link conveys AS_DATA_REQ. identifies the serial link (DLSAP) on which the block of data is to be transmitted.

82

AS_DATA_REQ

as_noclock_to

applies only if acknowledgements are configured for the link (see the parameter rdr_data_acks in the RDR_BIND_REQ on page 30 primitive.) This parameter determines the amount of time (in tenths of a second) allowed for transmission of the message. If the message is successfully transmitted prior to expiration of the specified time, the application will receive a RDR_DATA_ACK confirming transmission. If the message is not successfully transmitted before this time expires, the transmission is aborted, and a RDR_ERROR_ACK is returned with the rdr_errno field set to RDR_DATA_TIMEOUT. If this parameter is zero, this function is disabled.

State
This message is valid in state RDR_DATAXFER.

New State
The resulting state is unchanged.

Response
There is no response unless data acknowledgements are enabled, in which case RDR returns RDR_DATA_ACK or the request fails, in which case RDR returns RDR_ERROR_ACK.

Reasons for Failure


ENOLINK RDR_DATA_TIMEDOUT No DLSAP is bound to the connection. Failed to transmit message before timedout value.

83

Chapter 4: Control Primitives

TC_DATA_REQ
An application uses this primitive to send a block of data to RDR for transmission on a serial link either configured for the Thompson-CSF radar data format, the Thompson-TVT2 radar data format or the Toshiba radar data format. The link must be configured in diagnostic mode. The data supplied will be sent as a single Thompson-CSF, Thompson-TVT2 or Toshiba radar message.

Thompson-CSF Data Format


For Thompson-CSF, the RDR formats the message for transmission as follows:
Three sync characters and the SOH control characters are added to the start of the message. The two-byte header is taken from the control part of the primitive. A DLE-STX control sequence is added to separate the header and data within the message. DLE control sequences are added to the data as required for transparency. A DLE-ETX control sequence is added at the end of the data. The 16-bit BCC is calculated for transmission following the DLE-ETX sequence.

Thompson-TVT2 Data Format


For Thompson-TVT2, the RDR formats the message for transmission as follows:
Two sync characters and the SOH control characters are added to the start of the message. The two-byte header is taken from the control part of the primitive. A DLE-STX control sequence is added to separate the header and data within the message. DLE control sequences are added to the data as required for transparency. A DLE-ETX control sequence is added at the end of the data. In this case, ETX has the value 0x83. The 16-bit BCC is calculated for transmission following the DLE-ETX sequence.

Toshiba Data Format


For Toshiba, the RDR formats the message for transmission as follows:
Two sync characters are added to the start of the message. A DLE-STX control sequence is added to signify start of data. DLE control sequences are added to the data as required for transparency. A DLE-ETX control sequence is added at the end of the data. The 16-bit BCC is calculated for transmission following the DLE-ETX sequence.

If the resulting radar message that was produced with the data supplied in the TC_DATA_REQ request exceeds the maximum data size for the link, the request will be rejected, and the appropriate statistic (recv_2big) will be incremented. RDR guarantees to transmit each block in the same order as received from the application. When the data supplied with a TC_DATA_REQ has been completely transmitted and another TC_DATA_REQ is available for processing, RDR will begin transmitting the next block of data without interruption. If no new data is available for transmission, the serial line will idle ones (characters with the value 0xFF).

84

TC_DATA_REQ

Message Format
The control part of the message is defined by the following structure: typedef struct { bit32 tc_primitive; bit32 tc_link; bit32 tc_noclock_to; bit8 tc_hdr1; bit8 tc_hdr2; } tc_data_req_t; The data part of the message contains the block of data to be transmitted in the data portion of the radar message.

Parameters
tc_primitive tc_link tc_noclock_to conveys TC_DATA_REQ. identifies the serial link (DLSAP) on which the block of data is to be transmitted. applies only if acknowledgements are configured for the link (see the parameter rdr_data_acks in the RDR_BIND_REQ on page 30 primitive.) This parameter determines the amount of time (in tenths of a second) allowed for transmission of the message. If the message is successfully transmitted prior to expiration of the specified time, the application will receive a RDR_DATA_ACK confirming transmission. If the message is not successfully transmitted before this time expires, the transmission is aborted, and a RDR_ERROR_ACK is returned with the rdr_errno field set to RDR_DATA_TIMEOUT. If this parameter is zero, this function is disabled. contains the value to be transmitted in the first byte of the two-byte header. For Toshiba Radar, this value is not used. contains the value to be transmitted in the second byte of the two-byte header. For Toshiba Radar, this value is not used. Byte 1
1aaaaaaa

tc_hdr1 tc_hdr2

Byte 2
Bbbbbbbb

Byte 3
Cccccccc

Byte 4
Dddddddd

State
This message is valid in state RDR_DATAXFER.

New State
The resulting state is unchanged.

85

Chapter 4: Control Primitives

Response
There is no response unless data acknowledgements are enabled, in which case RDR returns RDR_DATA_ACK or if the request fails, in which case RDR returns RDR_ERROR_ACK.

Reasons for Failure


ENOLINK EACCESS RDR_DATA_TIMEDOUT RDR_BAD_DATA_FORMAT RDR_BAD_DATA_BLOCK No DLSAP is bound to the connection. The connection is not configured for diagnostic mode. Failed to transmit message before timeout value. The control structure is not of valid format. The data part of the request does not exist.

86

TP_DATA_REQ

TP_DATA_REQ
An application uses this primitive to send a block of data to RDR for transmission on a serial link configured for the TPS-43 or TPS-75 radar data format. The link must be configured in diagnostic mode. The data supplied will be divided into n 14 byte sized data blocks, or 16 byte sized data blocks for TPS43_C. Each data block will then be sent as a TPS-43 or TPS-75 radar message. If the total data size is not divisible by 14 (or 16 for TPS43_C), the remaining data will be rejected, and an informational statistic (tp_xmt_rjct) will be incremented.

TPS43_A
The RDR formats a TPS43_A variant radar message for transmission as follows:
Two start groups are added to the beginning of the message. A parity group (odd parity of the preceding 16 groups) is added to the end of the message.

TPS43_B
For a TPS43_B variant radar message, the RDR assumes that each data group has the proper mark bit set. The RDR formats a TPS43_B variant radar message for transmission as follows:
One start group is added to the beginning of the message. A parity group (odd parity of the preceding 14 groups) is added to the end of the message.

TPS43_C
For a TPS43_C variant radar message (besides Enhanced TPS43_C described below), the RDR assumes that each message to send out has one start group at the beginning of the message followed by 14 data groups with a parity group (odd parity) in the middle, all with the proper mark bit set for each group.

Enhanced TPS43_C
For an Enhanced TPS43_C radar message, all formatting of a 98 bit message will be done by the transmitter (the final mark bit must be set for each message in the raw data or the message will be rejected). Since a 98 bit message does not fall on an 8 bit boundary, the last message bundled to be sent must be padded out with zeros to the next byte boundary. No padding is expected between back-to-back messages.

TPS43_D
For a TPS43_D variant radar message, the RDR assumes that each data group has the proper mark bit set. The RDR formats a TPS43_D variant radar message for transmission as follows:
One start group is added to the beginning of the message. A parity group (odd parity of the preceding 14 groups, which consists of a single, fixed bit, followed by 6 check bits, followed by a final bit) is added to the end of the message.

87

Chapter 4: Control Primitives

TPS-75
For a TPS-75 radar message, the RDR formats a radar message for transmission as follows:
One start group is added to the beginning of the message. One mark bit is added to each of the 14 data groups. A parity group (odd parity of the preceding 14 data groups) is added to the end of the message.

If the resulting radar messages that were produced with the data supplied in the TP_DATA_REQ request exceeds the maximum data size for the link, the request will be rejected, and the appropriate statistic (tp_xmit_2big) will be incremented. RDR guarantees to transmit each block in the same order as received from the application. When the data supplied with a TP_DATA_REQ has been completely transmitted and another TP_DATA_REQ is available for processing, RDR will begin transmitting the next block of data without interruption. If no new data is available for transmission, the serial line will idle the idle character which was specified in the bind request (tp_idle).

Message Format
The control part of the message is defined by the following structure: typedef struct { bit32 tp_primitive; bit32 tp_link; bit32 tp_noclock_to; } tp_data_req_t; The data part of the message contains the block of data to be transmitted in the data portion of the radar message.

Parameters
tp_primitive tp_link tp_noclock_to conveys TP_DATA_REQ. identifies the serial link (DLSAP) on which the block of data is to be transmitted. applies only if acknowledgements are configured for the link (see the parameter rdr_data_acks in the RDR_BIND_REQ, on page 30 primitive.) This parameter determines the amount of time (in tenths of a second) allowed for transmission of the message. If the message is successfully transmitted prior to expiration of the specified time, the application will receive a RDR_DATA_ACK confirming transmission. If the message is not successfully transmitted before this time expires, the transmission is aborted, and a RDR_ERROR_ACK is returned with the rdr_errno field set to RDR_DATA_TIMEOUT. If this parameter is zero, this function is disabled.

88

TP_DATA_REQ

State
This message is valid in state RDR_DATAXFER.

New State
The resulting state is unchanged.

Response
There is no response unless data acknowledgements are enabled, in which case RDR returns RDR_DATA_ACK or the request fails, in which case RDR returns RDR_ERROR_ACK.

Reasons for Failure


ENOLINK EACCESS RDR_DATA_TIMEDOUT RDR_BAD_DATA_FORMAT RDR_BAD_DATA_BLOCK No DLSAP is bound to the connection. The connection is not configured for diagnostic mode. Failed to transmit message before timeout value. The control structure is not of valid format. The data part of the request does not exist.

89

Chapter 4: Control Primitives

RADUGA2_DATA_REQ
An application uses this primitive to send a block of data to RDR for transmission on a serial link configured for the Raduga-2 radar data format. The link must be configured in RDR_WRITEONLY or RDR_READWRITE mode. The data supplied will be used as the payload section for the applicable Raduga-2 30-bit word messages that get generated based on the Message Length and Message Identifiers values.

Message Format
The control part of the message is defined by the following structure: typedef struct { bit32 raduga2_primitive; bit32 raduga2_link; bit32 raduga2_noclock_to; bit32 raduga2_message_length; bit32 raduga2_message_identifier; } raduga2_data_req_t; The data part of the message contains the block of data to be transmitted in the data portion of the radar message.

Parameters
raduga2_primitive conveys RADUGA2_DATA_REQ. raduga2_link identifies the serial link (DLSAP) on which the block of data is to be transmitted.

raduga2_noclock_to applies only if acknowledgements are configured for the link (see the parameter rdr_data_acks in the RDR_BIND_REQ on page 30 primitive). This parameter determines the amount of time (in tenths of a second) allowed for transmission of the message. If the message is successfully transmitted prior to expiration of the specified time, the application will receive a RDR_DATA_ACK confirming transmission. If the message is not successfully transmitted before this time expires, the transmission is aborted, and a RDR_ERROR_ACK is returned with the rdr_errno field set to RDR_DATA_TIMEOUT. If this parameter is zero, this function is disabled. raduga2_message_length conveys the number of 30-bit words that comprise the Raduga-2 message. This value will be reflected in bits 13-15 of the first 30-bit word of the message. Valid length values are: 1, 2, and 5. raduga2_message_identifier conveys the identifier type of the message. This value will be reflected in bits 16 and 17 of the first 30-bit word of the message. Valid values are: 0, 1, 2, and 3.

90

RADUGA2_DATA_REQ

State
This message is valid in state RDR_DATAXFER.

New State
The resulting state is unchanged.

Response
There is no response unless data acknowledgements are enabled, in which case RDR returns RDR_DATA_ACK or the request fails, in which case RDR returns RDR_ERROR_ACK.

Reasons for Failure


ENOLINK EACCESS RDR_DATA_TIMEDOUT RDR_BAD_DATA_FORMAT RDR_BAD_DATA_BLOCK No DLSAP is bound to the connection. The connection is not configured for diagnostic mode. Failed to transmit message before timeout value. The control structure is not of valid format. The data part of the request does not exist.

91

Chapter 4: Control Primitives

RDR_DATA_IND
When radar messages are received on a connection, RDR uses this primitive to convey the messages to the application. RDR also sends this primitive on a periodic basis when the link is idle (no valid Radar Receiver messages are received) or non-operational (no valid idle characters are received). The non-operational state applies only to CD-2, Marconi, Modified Eurocontrol, General 18-Bit and NEC Radar Extractor. The circumstances under which RDR forwards a block of messages to the application is determined by configuration parameters included with the RDR_BIND_REQ. An RDR_DATA_IND primitive is sent to the application when the maximum number of messages is received or when the timeout period expires, whichever occurs first. (See A Note About Configuration, on page 99 for details.) For any given serial link, RDR guarantees to deliver each radar message to the application in the same order as received on that serial link. If more than one DLSAP is bound to the connection, messages received on different serial links are not necessarily in chronological sequence within an RDR_DATA_IND.

Message Format
The control part of the message is defined by the following structure: typedef struct { bit32 rdr_primitive; bit32 rdr_reason; bit32 rdr_msg_count; } rdr_data_ind_t; See rdr_data_ind_t RMH Structure Parameters, on page 94 for a description of each parameter. The data part of the message contains received radar messages, each of which is preceded by a radar message header (RMH) structure. The format of this structure is dependent on the radar data type, but the first field always specifies the serial link. The link number, which in turn identifies the radar type, can be used to determine the format of the remainder of the structure. In the general case, the RMH structure provides information related to a radar message, and is followed by the message itself. When no valid radar messages are received on a serial link within the configured timeout period, the RMH structure only signifies that no data was received, and is not followed by a radar message.

92

RDR_DATA_IND

CD-2 (FPS 117), Marconi 10-Bit, Modified Eurocontrol, General 18-Bit and NEC Radar Extractor RMH Structure
For CD-2 (FPS 117), Marconi 10-Bit, Modified Eurocontrol, General 18-Bit and NEC Radar Extractor, the RMH structure is defined as follows: typedef struct { bit32 bit32 struct utimeval wanStrProt_timeStatus_t bit32 bit32 } cd_message;

cd_link; cd_time_stamp; cd_sntp_time_stamp; cd_timeStatus; cd_length; cd_idles;

See cd_message RMH Structure Parameters, on page 95 for a description of each parameter.

ASTERIX RMH Structure


For ASTERIX, the RMH structure is defined as follows: typedef struct { bit32 bit32 struct utimeval wanStrProt_timeStatus_t bit32 bit32 } as_message;

as_link; as_time_stamp; as_sntp_time_stamp; as_timeStatus; as_length; as_reserved;

See as_message RMH Structure Parameters, on page 96 for a description of each parameter.

Thompson-CSF, Thompson-TVT2 and Toshiba RMH Structure


For Thompson-CSF, Thompson-TVT2 and Toshiba, the RMH structure is defined as follows: typedef struct { bit32 bit32 struct utimeval wanStrProt_timeStatus_t bit32 bit8 bit8 bit16 } tc_message;

tc_link; tc_time_stamp; tc_sntp_time_stamp; tc_timeStatus; tc_length; tc_hdr1; tc_hdr2; tc_reserved;

93

Chapter 4: Control Primitives

See tc_message RMH Structure Parameters, on page 96 for a description of each parameter.

TPS-43 and TPS-75 RMH Structure


For TPS-43 and TPS-75, the RMH structure is defined as follows: typedef struct { bit32 bit32 struct utimeval wanStrProt_timeStatus_t bit32 bit32 } tp_message;

tp_link; tp_time_stamp; tp_sntp_time_stamp; tp_timeStatus; tp_length; tp_reserved;

See tp_message RMH Structure Parameters, on page 97 for a description of each parameter.

Raduga-2 RMH Structure


For Raduga-2, the RMH structure is defined as follows: typedef struct { bit32 bit32 struct utimeval wanStrProt_timeStatus_t bit32 raduga2_info_t bit16 } raduga2_message;

raduga2_link; raduga2_time_stamp; raduga2_sntp_time_stamp; raduga2_timeStatus; raduga2_length; raduga2_info; raduga2_reserved;

See raduga2_message RMH Structure Parameters, on page 98 for a description of each parameter.

Parameters
rdr_data_ind_t RMH Structure Parameters
In the rdr_data_ind_t structure: rdr_primitive rdr_reason conveys RDR_DATA_IND. indicates the reason for the RDR_DATA_IND, as follows: DL_TIMEDOUT The RDR timeout value was reached before the maximum number of radar messages was received. DL_BUFFULL The maximum number of radar messages was received before the timeout occurred.

94

RDR_DATA_IND

(The RDR timeout value and maximum number of messages are configured as part of the bind request.) rdr_msg_count specifies the number of RMH structures within the data block.

cd_message RMH Structure Parameters


In the cd_message RMH structure: cd_link cd_time_stamp identifies the serial link on which the message was received (and indirectly identifies the radar data format). contains the time stamp (tick count), recorded at the time the first byte of the message was received.

cd_sntp_time_stamp contains the optional SNTP timestamp applied to received message blocks. This field only applies to certain models of PTI LAN-based servers. The timestamp is reported in a structure that consists of two fields: the number of seconds and the number of microseconds of Universal Coordinated Time (UTC). cd_timeStatus specifies the external timestamp status if it is being used (see the parameter options1 of the appropriate Bind Request RDR_BIND_REQ on page 30). This parameter is an enumeration and is treated as a bit field where more than one feature can be or'd together. This feature only applies to the NexusWare base Protocol controllers. The bit definitions are:
WANSTRPROT_TS_CLOCK_NOT_LOCKED (0x00000001)

indicates that the external clock's external synchronization signal is either unstable or missing.
WANSTRPROT_TS_CLOCK_NOT_SYNCED (0x00000002)

indicates that the external clock has not yet synchronized to the external synchronization signal.
WANSTRPROT_TS_CLOCK_INACCURATE (0x00000004)

indicates that the external clocks internal oscillator is not accurate and could indicate a hardware problem. cd_length identifies the size of the received radar message, in bytes. If length is zero, no messages were received on the serial link within the configured timeout period. specifies the number of received idle characters that preceded the associated radar message (the number of idles since the previous message was received, or since synchronization was achieved). The value of idles is valid even if length is zero. If idles is zero, the serial link is not operating correctly.

cd_idles

95

Chapter 4: Control Primitives

as_message RMH Structure Parameters


In the as_message RMH structure: as_link as_time_stamp identifies the serial link on which the message was received (and indirectly identifies the radar data format). contains the time stamp (tick count), recorded at the time the first byte of the message was received.

as_sntp_time_stamp contains the optional SNTP timestamp applied to received message blocks. This field only applies to certain models of PTI LAN-based servers. The timestamp is reported in a structure that consists of two fields: the number of seconds and the number of microseconds of Universal Coordinated Time (UTC). as_timeStatus specifies the external timestamp status if it is being used (see the parameter options1 of the appropriate Bind Request RDR_BIND_REQ on page 30). This parameter is an enumeration and is treated as a bit field where more than one feature can be or'd together. This feature only applies to the NexusWare base Protocol controllers. The bit definitions are:
WANSTRPROT_TS_CLOCK_NOT_LOCKED (0x00000001)

indicates that the external clock's external synchronization signal is either unstable or missing.
WANSTRPROT_TS_CLOCK_NOT_SYNCED (0x00000002)

indicates that the external clock has not yet synchronized to the external synchronization signal.
WANSTRPROT_TS_CLOCK_INACCURATE (0x00000004)

indicates that the external clocks internal oscillator is not accurate and could indicate a hardware problem. as_length identifies the size of the received radar message, in bytes. If length is zero, no messages were received on the serial link within the configured timeout period. is not used.

as_reserved

tc_message RMH Structure Parameters


In the tc_message RMH structure: tc_link tc_time_stamp identifies the serial link on which the message was received. contains the time stamp (tick count), recorded at the time the first byte of the message was received.

96

RDR_DATA_IND

tc_sntp_time_stamp contains the optional SNTP timestamp applied to received message blocks. This field only applies to certain models of PTI LAN-based servers. The timestamp is reported in a structure that consists of two fields: the number of seconds and the number of microseconds of Universal Coordinated Time (UTC). tc_timeStatus specifies the external timestamp status if it is being used (see the parameter options1 of the appropriate Bind Request RDR_BIND_REQ on page 30). This parameter is an enumeration and is treated as a bit field where more than one feature can be or'd together. This feature only applies to the NexusWare base Protocol controllers. The bit definitions are:
WANSTRPROT_TS_CLOCK_NOT_LOCKED (0x00000001)

indicates that the external clock's external synchronization signal is either unstable or missing.
WANSTRPROT_TS_CLOCK_NOT_SYNCED (0x00000002)

indicates that the external clock has not yet synchronized to the external synchronization signal.
WANSTRPROT_TS_CLOCK_INACCURATE (0x00000004)

indicates that the external clocks internal oscillator is not accurate and could indicate a hardware problem. tc_length identifies the size of the data portion of either the Thompson-CSF radar message, the Thompson-TVT2 radar message or the Toshiba radar message, in bytes. If length is zero, no messages were received on the serial link within the configured timeout period. for either a Thompson-CSF or a Thompson-TVT2 radar message, contains the first byte of the two-byte header. For a Toshiba radar message, this field is not used. for either a Thompson-CSF or a Thompson-TVT2 radar message, contains the second byte of the two-byte header. For a Toshiba radar message, this field is not used. is not used.

tc_hdr1

tc_hdr2

tc_reserved

tp_message RMH Structure Parameters


In the tp_message RMH structure: tp_link tp_time_stamp identifies the serial link on which the message was received. contains the time stamp (tick count), recorded at the time the first byte of the message was received.

97

Chapter 4: Control Primitives

tp_sntp_time_stamp contains the optional SNTP timestamp applied to received message blocks. This field only applies to certain models of PTI LAN-based servers. The timestamp is reported in a structure that consists of two fields: the number of seconds and the number of microseconds of Universal Coordinated Time (UTC). tp_timeStatus specifies the external timestamp status if it is being used (see the parameter options1 of the appropriate Bind Request RDR_BIND_REQ on page 30). This parameter is an enumeration and is treated as a bit field where more than one feature can be or'd together. This feature only applies to the NexusWare base Protocol controllers. The bit definitions are:
WANSTRPROT_TS_CLOCK_NOT_LOCKED (0x00000001)

indicates that the external clock's external synchronization signal is either unstable or missing.
WANSTRPROT_TS_CLOCK_NOT_SYNCED (0x00000002)

indicates that the external clock has not yet synchronized to the external synchronization signal.
WANSTRPROT_TS_CLOCK_INACCURATE (0x00000004)

tp_length

identifies the size of the data portion of the TPS-43 or TPS-75 radar message, in bytes. If length is zero, no messages were received on the serial link within the configured timeout period. is not used.

tp_reserved

raduga2_message RMH Structure Parameters


In the raduga2_message RMH structure: raduga2_link identifies the serial link on which the message was received.

raduga2_time_stamp contains the time stamp (tick count), recorded at the time the first byte of the message was received. raduga2_sntp_time_stamp contains the optional SNTP timestamp applied to received message blocks. This field only applies to certain models of PTI LAN-based servers. The timestamp is reported in a structure that consists of two fields: the number of seconds and the number of microseconds of Universal Coordinated Time (UTC). raduga2_timeStatus specifies the external timestamp status if it is being used (see the parameter options1 of the appropriate Bind Request RDR_BIND_REQ on page 30). This parameter is an enumeration and is treated as a bit field where more than one feature can be or'd together. This feature only applies to the NexusWare base Protocol controllers. The bit definitions are:

98

RDR_DATA_IND

WANSTRPROT_TS_CLOCK_NOT_LOCKED (0x00000001)

indicates that the external clock's external synchronization signal is either unstable or missing.
WANSTRPROT_TS_CLOCK_NOT_SYNCED (0x00000002)

indicates that the external clock has not yet synchronized to the external synchronization signal.
WANSTRPROT_TS_CLOCK_INACCURATE (0x00000004)

raduga2_length

identifies the size of the data portion of the Raduga-2 radar message, in bytes. If length is zero, no messages were received on the serial link within the configured timeout period. contains the Raduga-2 Message Length and Message Identifier values. is not used.

raduga2_info raduga2_reserved

A Note About Configuration


With each bind request (RDR_BIND_REQ), the application specifies a timeout value and maximum number of messages for the radar mux and a timeout value and maximum number of messages for the radar protocol module, see Table 4-3: Timeout and Messages Parameters. Table 4-3: Timeout and Messages Parameters Module
Radar Mux CD-2, Marconi ASTERIX Thompson-CSF Thompson-TVT2 Toshiba TPS-43 Modified Eurocontrol General 18-Bit NEC Radar Extractor TPS-75 Raduga-2

Structure
rdr_bind_req_t cd_bind_req_t as_bind_req_t tc_bind_req_t tc_bind_req_t tc_bind_req_t tp_bind_req_t cd_bind_req_t cd_bind_req_t cd_bind_req_t tp_bind_req_t raduga2_bind_req_t

Timeout Parameter
rdr_message_timeout cd_fwd_time as_fwd_time tc_fwd_time tc_fwd_time tc_fwd_time tp_fwd_time cd_fwd_time cd_fwd_time cd_fwd_time tp_fwd_time raduga2_fwd_time

Messages Parameter
rdr_max_messages cd_maxmesg_cnt as_framesize tc_maxmesg_cnt tc_maxmesg_cnt tc_maxmesg_cnt tp_maxmesg_cnt cd_maxmesg_cnt cd_maxmesg_cnt cd_maxmesg_cnt tp_maxmesg_cnt raduga2_maxmesg_cnt

Each timeout and counter pair operates independently, as follows:


If the length field (cd_length, as_length, tc_length, tp_length, raduga2_length) of the RMH structure is zero, the next RMH follows immediately. For CD-2, Marconi, Thompson-CSF, Thompson-TVT2, Toshiba, TPS-43, TPS-75, Modified Eurocontrol, General 18-Bit, NEC Radar Extractor and Raduga-2, if the length field is non-zero the RMH is followed by a fixed number of data bytes. This number depends on the maximum message size configured for the serial link. The size specified by this parameter is rounded up to a multiple of four to determine the fixed data length following the RMH structure. (The actual number of valid bytes

99

Chapter 4: Control Primitives

within that data is determined by the cd_length, tc_length. tp_length or raduga2_length field of the RMH structure). When the radar mux has received its maximum number of radar messages (compiled from all lower streams bound to the connection), it sends an RDR_DATA_IND upstream to the application. When the radar Muxs timeout expires before the maximum number of messages has been received from the lower streams, it sends an RDR_DATA_IND upstream to the application containing the messages it has received. However, if no messages are received from the lower streams during the timeout period, the radar mux sends no indication to the application. Depending on the configured timeout periods, an RDR_DATA_IND may include one or more empty (RMH-structure-only) messages from any or all of the bound serial links.

Data Format
The data portion of the RDR_DATA_IND primitive consists of one or more RMH structures, each of which is followed by a variable number of data bytes. The rdr_msg_count field of the rdr_data_ind_t structure indicates the total number of RMH structures included in the data. The offset from one RMH structure to the next is determined as follows:
If the length field (cd_length, as_length, tc_length, or tp_length) of the RMH structure is zero, the next RMH follows immediately. For CD-2, Marconi, Thompson-CSF, Thompson-TVT2, Toshiba, TPS-43, TPS-75, Modified Eurocontrol, General 18-Bit, and NEC Radar Extractor, if the length field is non-zero the RMH is followed by a fixed number of data bytes. This number depends on the maximum message size configured for the serial link. The size specified by this parameter is rounded up to a multiple of four to determine the fixed data length following the RMH structure. (The actual number of valid bytes within that data is determined by the cd_length, tc_length or tp_length field of the RMH structure.) For ASTERIX, if cd_length is non-zero the RMH is followed by as_length bytes rounded up to a multiple of four. (The as_length field specifies the actual number of valid bytes in the message.)

Message Format
Within the message data following the RMH structure, the format of the radar message itself depends on the radar data type. For CD-2, Marconi, Modified Eurocontrol and General 18-Bit, the format additionally depends on the value of the cd_packmesg parameter included in the bind request. In the diagrams below, each word of radar data is shown as a string of alphabetic characters, with the most-significant bit of the word in upper case.

100

RDR_DATA_IND

CD-2 (FPS 117) Configured for Packed Data


The number of valid data bytes is determined by the value of the cd_length field in the cd_message structure. The radar message is stored in the first cd_length bytes following the RMH, formatted as a continuous bit stream. (For example, the first two bytes contain the first 13-bit word and the most-significant three bits of the second word.) Depending on the message length, the last valid byte of the message may contain up to seven unused bits (in the low-order portion of the byte). Byte 1
Aaaaaaaa

Byte 2
aaaaaBbb

Byte 3
bbbbbbbb

Byte 4
bbCccccc ...

CD-2 (FPS 117) Configured for Unpacked Data


The number of valid data bytes is determined by the value of the cd_length field in the cd_message structure. The radar message is stored in the first cd_length bytes following the RMH. Each pair of bytes (16-bit word) contains a single CD-2 13-bit word in the low order bits, and the high-order three bits are set to zero. Byte 1
000Aaaaa

Byte 2
aaaaaaaa

Byte 3
000Bbbbb

Byte 4
bbbbbbbb ...

Marconi 10-Bit Configured for Packed Data


The number of valid data bytes is determined by the value of the cd_length field in the cd_message structure. The radar message is stored in the first cd_length bytes following the RMH, formatted as a continuous bit stream. (For example, the first two bytes contain the first 10-bit word and the most-significant six bits of the second word.) Depending on the message length, the last valid byte of the message may contain up to seven unused bits (in the low-order portion of the byte). Byte 1
Aaaaaaaa

Byte 2
aaBbbbbb

Byte 3
bbbbCccc

Byte 4
ccccccDd ...

Marconi 10-Bit Configured for Unpacked Data


The number of valid data bytes is determined by the value of the cd_length field in the cd_message structure. The radar message is stored in the first cd_length bytes following the RMH. Each pair of bytes (16-bit word) contains a single Marconi 10-bit word in the low order bits, and the high-order six bits are set to zero. Byte 1
000000Aa

Byte 2
aaaaaaaa

Byte 3
000000Bb

Byte 4
bbbbbbbb ...

101

Chapter 4: Control Primitives

NEC Radar Extractor


The number of valid data bytes is determined by the value of the cd_length field in the cd_message structure. The first bit of the first byte of the data should have a value of 1. Any byte of the value of 0x00 is considered an idle character, and is not included in the data. The radar message, which consists of byte-aligned eight-bit values, is stored in the first cd_length bytes following the RMH.

ASTERIX
The number of valid data bytes is determined by the value of the as_length field in the as_message structure. The radar message, which consists of byte-aligned eight-bit values, is stored in the first as_length bytes following the RMH. Byte 1
Aaaaaaaa

Byte 2
Bbbbbbbb

Byte 3
Cccccccc

Byte 4
Dddddddd ...

Thompson-CSF, Thompson-TVT2 and Toshiba


Each of the Thompson-CSF, Thompson-TVT2 and Toshiba radar messages consists of a twobyte header and a variable number of data bytes. The header bytes are stored in the tc_hdr1 and tc_hdr2 fields of the tc_message structure. The number of valid data bytes is determined by the value of the tc_length field. The radar message is stored in the first tc_length bytes following the RMH, and consists of byte-aligned eight-bit values. Byte 1
Aaaaaaaa

Byte 2
Bbbbbbbb

Byte 3
Cccccccc

Byte 4
Dddddddd ...

TPS-43
Each of the TPS-43 radar messages consists of fourteen data groups. The message format of a received TPS-43 variant radar message is as follows, except for Enhanced TPS43_C, which is described below. The sync character(s) and the parity byte have been stripped out, except for non-enhanced TPS43_C. The number of valid data bytes is determined by the value of the tp_length field, which should be 14. The radar message is stored in the first tp_length bytes following the RMH, and consists of byte-aligned eight-bit values. Mark bits (if applicable) are not stripped out. For Enhanced TPS43_C, the sync character, mark bits, and the parity byte have been stripped out. The final mark bit is included with the data. The number of valid data bytes is determined by the value of the tp_length field, which is 13. The radar message is stored in the first tp_length bytes following the RMH. Since an Enhanced TPS43_C message is 98 bits and does not land on an 8 bit boundary, byte 13 is padded with zeros after the two data bits.

102

RDR_DATA_IND

Modified Eurocontrol and General 18-Bit Configured for Packed Data


The number of valid data bytes is determined by the value of the cd_length field in the cd_message structure. The radar message is stored in the first cd_length bytes following the RMH, formatted as a continuous bit stream. (For example, the first three bytes contain the first 18-bit word and the most-significant six bits of the second word.) Depending on the message length, the last valid byte of the message may contain up to seven unused bits (in the low-order portion of the byte). Byte 1
Aaaaaaaa

Byte 2
aaaaaaaa

Byte 3
aaBbbbbb

Byte 4
bbbbbbbb

Byte5
bbbbCccc ...

Modified Eurocontrol and General 18-Bit Configured for Unpacked Data


The number of valid data bytes is determined by the value of the cd_length field in the cd_message structure. The radar message is stored in the first cd_length bytes following the RMH. Each sequence of four bytes (32-bit long word) contains a single General 18-Bit Modified Eurocontrol or 18-bit word in the low order bits, and the high-order 14 bits are set to zero. Byte 1
00000000

Byte 2
000000Aa

Byte 3
aaaaaaaa

Byte 4
aaaaaaaa

Byte 5
00000000

Byte 6
000000Bb

Byte 7
bbbbbbbb

Byte 8
bbbbbbbb ...

TPS-75
Each of the TPS-75 radar messages consists of fourteen data bytes. The sync character, mark bits, and the parity byte have been stripped out. The number of valid data bytes is determined by the value of the tp_length field, which should be 14. The radar message is stored in the first tp_length bytes following the RMH, and consists of byte-aligned eight-bit values. Byte 1
Aaaaaaaa

Byte 2
Bbbbbbbb

Byte 3
Cccccccc

Byte 4
Dddddddd ...

Raduga-2
Each Raduga-2 message consists of 2 to 13 bytes of actual data payload. The barker code, parity bit, mark bits and control patterns have all been stripped out. Also, all Silence Messages are discarded. The radar message is stored in the first raduga2_length bytes following the RMH, and consists of byte-aligned eight-bit values. Byte 1
Aaaaaaaa

Byte 2
Bbbbbbbb

Byte 3
Cccccccc

Byte 4
Dddddddd ...

103

Chapter 4: Control Primitives

Example
Figure 4-1, Sample Message Formats, on page 105 shows two sample RDR_DATA_IND primitives containing radar messages received on four serial links, numbered 0 through 3. Table 4-4: Sample Message Format Configuration shows the configuration for the links in this example: Table 4-4: Sample Message Format Configuration Link
0 1 2 3

Radar Type
CD-2 ASTERIX Thompson-CSF Marconi 10-Bit

cd_packmesg
1 n/a n/a 0

Max Message Size


12 n/a 28 24

The data part of the first RDR_DATA_IND contains four RMH structures (rdr_msg_count = 4). The first RMH is followed by a 9-byte message (cd_length = 9) from link 0 (cd_link = 0). Since link 0 is configured for packed data, the CD-2 message consists of 5 13-bit words, with the low-order 7 bits of the 9th byte unused. Since the maximum message size for this link was configured as 12 bytes, there are 3 unused bytes following the CD-2 message. The second RMH is also followed by a message from link 0. This message is 12 bytes. The low-order 5 bits of the 12th byte are unused, and the next RMH immediately follows the 12th byte of the radar message. The third RMH is an indication from link 3 that no messages were received during the timeout period configured for the radar data format on that link. Since cd_length = 0, the fourth RMH immediately follows the third.

104

RDR_DATA_IND

Figure 4-1: Sample Message Formats


Message 1
RDR_DATA_IND DL_TIMEDOUT rdr_mesg_cnt = 4

Message 2 Control Part


RDR_DATA_IND DL_TIMEDOUT rdr_mesg_cnt = 3

cd_link = 0 cd_time_stamp cd_sntp_time_stamp cd_length = 9 cd_idles CD-2 Message


unused

Data Part

cd_link = 3 cd_time_stamp cd_sntp_time_stamp cd_length = 14 cd_idles


Marconi Message

cd_link = 0 cd_time_stamp cd_sntp_time_stamp cd_length = 12 cd_idles CD-2 Message cd_link = 3 cd_time_stamp cd_sntp_time_stamp cd_length = 0 cd_idles tc_link = 2 tc_time_stamp tc_sntp_time_stamp tc_length = 18 header reserved

unused

as_link = 1 as_time_stamp as_sntp_time_stamp as_length = 22 as_reserved ASTERIX Message


unused

tc_link = 2 tc_time_stamp tc_sntp_time_stamp tc_length = 12 header reserved

Thompson-CSF Message Data

Thompson-CSF Message Data unused

unused

The fourth RMH is followed by the 18-byte data part of a Thompson-CSF message from link 2. Since the link is configured for a maximum message size of 28, the 18 bytes of the message are followed by 10 unused bytes. The data part of the second RDR_DATA_IND contains three RMH structures. The first, from link 3, is followed by a 14-byte Marconi message. Link 3 is configured for unpacked data and a maximum message size of 24. Therefore, the message contains 7 10-bit words, contained in the low order 10 bits of each of the first 7 16-bit words; and there are 10 unused bytes before the next RMH. The second RMH is followed by a 22-byte ASTERIX message from link 1. For ASTERIX, the message size is rounded up to a four-byte boundary to determine the start of the next RMH. In this case, this results in 2 unused bytes before the final RMH.

105

Chapter 4: Control Primitives

The third and last RMH, from link 2, is followed by the 12-bytes of data from a Thompson-CSF message, followed by 16 unused bytes.

State
This message is valid in state RDR_DATAXFER.

New State
The resulting state is unchanged.

106

Chapter 5
Sample Test Programs

Overview
As examples of the interface to RDR, three test programs are included in source form release. They are called rdrcv, rdrxmt and rdrtest, and are located in the Radar Client directory. The test programs accept a number of command-line parameters for configuration of the general test environment, and interactively prompt for information regarding each serial link to be tested. The information requested includes link number, radar data format, configuration parameters for the bind, and filenames. Topics included in this chapter include:
Test Parameters, on page 108 Run the Transmit and Receive Test Programs, on page 110 Run the Full Duplex Radar Test Program, on page 114

Receive Test Program


The rdrcv program receives data for all specified serial links on one connection, sorts it based on the serial link from which it was received, and writes each message to the specified file for that link. If requested to configure a link to pack received messages, rdrcv unpacks the data received from that link before writing it to the output file.

Transmit Test Program


The rdrxmt program opens a transmit (WRITEONLY) connection for the specified serial link, reads data from the specified file and sends it to RDR for transmission on that link.

Full Duplex Radar Test Program


The rdrtest program demonstrates how to open and use a serial link for both reading and writing (READWRITE). This program has a conditional compile statement in it which will allow it to run with and without the radar daemon being present. Look for NO_DAEMON in the file rdrtest.c. Only QUICC based platforms (e.g. MPS300/600, Sbus 334, PCI/CPC 334) can be configured for reading and writing on the same port. Other platforms will return an error if the bind request has READWRITE specified for the connection type.

107

Chapter 5: Sample Test Programs

Test Parameters
The command lines for the three test programs are defined as follows:
rdrxmt [-b [-n [-s [-W [-b [-f [-M [-P [-t baud] [-c controller] [-D acks option] [-i] [-M] protocol] [-O timestamps option] [-P physical IF] server] [-T message limit] [-v service] [-w] conntype] baud] [-c controller] [-D dump timestamp to file] [-F] SNTP timestamp frequency] [-i] [-m msg_per_block] multicast opt] [-n protocol] [-O timestamps option] physical IF] [-s server] [-S show timestamp] block_timeout] [-v service] [-w] [-W conntype]

rdrcv

rdrtest

[-b baud] [-c controller] [-D acks option] [-e Asterix encoding] [-f framesize] [-l linkno] [-L] [-M] [-O timestamps option] [-p proto] [-P physical IF] [-r rcvfile] [-s server] [-v service] [-w] [-W conntype] [-x xmtfile]

Parameters
-b baud This parameter specifies the baud rate for the serial port. For external clocking (clock signal supplied by a modem or other external device), baud should be set to -1. External clocking is the default for rdrcv and rdrxmt; 9600 bps is the default for rdrtest. This parameter specifies the controller number. If not specified, controller defaults to 0. For rdrxmt and rdrtest, this parameter specifies what type of data acknowledgement the transmit connection should support. See the rdr_data_acks parameter in the request RDR_BIND_REQ on page 30 for details on the bit values.

-c controller -D acks option

-D dump timestamp to file For rdrcv, this parameter specifies that the timestamps that accompany the data are saved off into the file: "./acktest_ts_recv.txt". -e Asterix encoding Specific modulation encoding for the ASTERIX protocol. See the description for as_encoding in the primitive RDR_BIND_REQ on page 30 for more details. -F Merge Data from Data Acks in with Time Tag information. This is done in the Time Tag file.

-f SNTP timestamp frequency For rdrcv only. This parameter is used to throttle the frequency so that the timestamp information is printed to standard output.

108

Test Parameters

-f framesize

For rdrtest, this parameter is used to specify the maximum frame size for the link. It is rounded up to the nearest 4 byte boundary. The default is 512 bytes. This parameter specifies handling of input modem signals. If this option is not specified, a value of 0 (RDR_NO SIGS) is set and changes in modem signals are ignored by the driver. If this option is specified, a value of 1 (RDR_SIGS) is set and the application is notified upon a modem signals state change. This parameter identifies the serial link that will be associated with the connection. If not specified, the link defaults to 0. For rdrtest only. Continuous transmit of specified send file.

-i

-l linkno -L -M

multicast opt For rdrcv only. Based on the provided option value, the application will be configured as follows: MPSMULTICAST_CLIENT_CONTROL_CON (1) Will have the application configure the MPS Server to provide the receive links data to the specified multicast group address. MPSMULTICAST_CLIENT_STANDARD_CON (2) Will have the application retrieve its data from the specified multicast group address; not the MPS Server. This parameter is valid for rdrcv only, and determines the value of the bind request's rdr_max_messages field. If not specified, this parameter defaults to 10. Opens to the specified protocol without going through the radar multiplexor.

-m maxcount

-n

protocol

-O timestamps option Specifies the bit field of the options1 flag that can configure the link. See the rdr_options1 parameter in the RDR_BIND_REQ of the radar protocol for details on the bit values, RDR_BIND_REQ on page 30. -p proto This parameter is an ASCII string identifying the radar data format associated with the connection. The valid strings are: cd2, marconi10, asterix, thompcsf, toshiba, tps43, euro, gen18, nec and tps75. This is a required parameter. Specifies the physical interface for a CPC358. If this parameter is not specified, a value of 2 is used specifying an RS530 physical interface. See the parameter phyIf in the RDR_BIND_REQ primitive for details on other options, RDR_BIND_REQ, on page 30. This parameter is not applicable to any other controller. This parameter specifies the name of the file to receive. This is a required parameter.

-P physical IF

-r rcvfile

109

Chapter 5: Sample Test Programs

-s server

This parameter identifies the target server. For a LAN-based server, this is the logical host name as specified in the client's hosts database. For a controller installed in a backplane, server is the pathname of the driver's cloneable special file. If this option is not specified, the server name defaults to /dev/ucsclone for UNIX, and \\.\PTIXpqcc for Windows NT. For rdrcv, print detailed timestamp information for each received data message to the standard output.

-S show timestamp

-t timeout

This parameter is valid for rdrcv only, and determines the value of the bind request's rdr_message_timeout field. If not specified, this parameter defaults to 30 (3 seconds). Enable data acknowledgements. The number specified is the number of messages the client sends to the protocol before waiting to receive a data acknowledgement back from the protocol. For LAN-based servers, this parameter identifies the service name to be accessed, as specified in the client's services database. If this option is not specified, the service name defaults to mps. For a controller installed in a backplane, this parameter is not used. Specifies the connection type to use for the WPS registration process. See the WPS Registration command in the MPS-API User Manual for details on the different connection types available. Specifies to the application that a WPS connection will be established with the server. A WPS server has the links already configured, so the set up and registration process that the application performs is a bit different. See the WPS Registration command in the MPS-API Manual for details on a WPS connection. This parameter specifies the name of the file to transmit. This is a required parameter.

-T

-v service

-W conntype

-w

-x xmtfile

Run the Transmit and Receive Test Programs


To run the test programs, you must connect a loopback cable between two serial ports. You will specify one of the two links when prompted by rdrcv and the other when prompted by rdrxmt. If you have a LAN-based server, power it on and wait for it to download. If you have an embedded server, load it using the commload utility. (Download procedures are described in the MPS Software and Hardware Install Guide.) Start rdrcv first. The example shown below uses the default server name, controller number and baud rate, but sets the maximum message count to 40 and the timeout value to 50 (5 seconds).
rdrcv -m 40 -t 50

110

Run the Transmit and Receive Test Programs

The test program will prompt you for link configuration information. When you enter a receive filename, be careful to use a non-existent or scratch file. After you have configured the serial link on which you will be receiving data, enter a -1 (unless you want to configure additional links). The program then displays a menu prompting you for an output display mode. (It will optionally print a dot for each message received, or periodically request and display link statistics.) Once you have supplied all the requested information, rdrcv begins operation by opening a connection to RDR on the server. It does this using MPSopen with protocol name rdrmux. It then uses MPSputmsg to issue an RDR_BIND_REQ primitive for each specified serial link. After sending the bind request, rdrcv uses MPSgetmsg to obtain RDR's response, and exits in case of error. If the bind succeeds (RDR_BIND_ACK is received), rdrcv issues an MPSgetmsg request to wait for an RDR_DATA_IND primitive. Now start rdrxmt. The example shown below uses the default server name and controller number, and configures the line speed to 4800 bps.
rdrxmt -b 4800

Like rdrcv, rdrxmt prompts you for configuration information, but only allows you to configure a single link. When you have entered the requested information, rdrxmt opens a connection to RDR with protocol name rdrmux, issues an RDR_BIND_REQ for the specified serial link, and waits for the response. When a valid response is received, the program begins reading blocks of data from the specified file, using MPSputmsg to send them to RDR as CD_DATA_REQ, AS_DATA_REQ or TC_DATA_REQ primitives (depending on the radar data format selected). As the data supplied by rdrxmt is transmitted on one serial link, it is received, through the loopback cable on the link configured by rdrcv. RDR forwards the received data on the connection in the form of RDR_DATA_IND primitives. When rdrcv's MPSgetmsg call completes, the program parses the data portion of the RDR_DATA_IND primitive and writes the radar messages to the appropriate files based on the link number from which each message was received (after unpacking the data if necessary). rdrcv then issues another MPSgetmsg call to obtain the next RDR_DATA_IND. This process is repeated until you terminate the program by typing a CTRL-C. Before rdrcv terminates, it displays its own statistics regarding received messages, and then requests statistics from RDR for each serial link and displays those as well.

rdrcv Example
A sample execution of rdrcv is shown below, demonstrating responses to its interactive prompts.
$ rdrcv -s radarbox LINK CONFIGURATION link number (-1 to continue) [0]: 0) cd2 1) marconi10 2) asterix

111

Chapter 5: Sample Test Programs

3) thompcsf 4) euro 5) gen18 6) toshiba 7) tps43 8) nec 9) tps75 10) raduga2 protocol [0]: Framesize [256]: Timeout baud [9600]: Reply timeout [30]: Pack messages (0 = no, 1 = yes) [0]: Invert data (0 = no, 1 = yes) [0]: Name of receive file: rcv0 link number (-1 to continue) [-1]: 2 0) cd2 1) marconi10 2) asterix 3) thompcsf 4) euro 5) gen18 6) toshiba 7) tps43 8) nec 9) tps75 10) raduga2 protocol [0]: 3 Framesize [256]: 128 Timeout baud [9600]: Reply timeout [30]: Name of receive file: rcv2 link number (-1 to continue) [-1]: 4 0) cd2 1) marconi10 2) asterix 3) thompcsf 4) euro 5) gen18 6) toshiba 7) tps43 8) nec 9) tps75 10) raduga2 protocol [0]: 1 Framesize [256]: 128 Timeout baud [9600]: 4800 Reply timeout [30]: 40

112

Run the Transmit and Receive Test Programs

Pack messages (0 = no, 1 = yes) [0]: 1 Invert data (0 = no, 1 = yes) [0]: Name of receive file: rcv4 link number (-1 to continue) [-1]: 6 0) cd2 1) marconi10 2) asterix 3) thompcsf 4) euro 5) gen18 6) toshiba 7) tps43 8) nec 9) tps75 10) radagu2 protocol [0]: 2 Framesize [256]: 512 Timeout baud [9600]: 2400 Reply timeout [30]: 40 Which data encoding method for ASTERIX? -------------------------------------------0) NRZ 1) NRZI 2) FM0 for RAMP Radar 3) FM1 4) Manchester 5) Differential Manchester Choice [0]: 0 Name of receive file: rcv6 link number (-1 to continue) [-1]: Sending Open Server Request. M E N U P Print A Dot For Each Block Received S Print rdrcv Statistics At Periodic Intervals Option [P]:

rdrxmt Example
A sample execution of rdrxmt is shown below, demonstrating responses to its interactive prompts.
$ rdrxmt -b 4800 -s radarbox LINK CONFIGURATION link number [1]: 0) cd2

113

Chapter 5: Sample Test Programs

1) marconi10 2) asterix 3) thompcsf 4) euro 5) gen18 6) toshiba 7) tps43 8) nec 9) tps75 10) raduga2 protocol [0]: Framesize [130]: Invert data (0 = no, 1 = yes) [0]: non 8-bit idle (0 - no, 1 - yes) [1]: Idle pattern (hex) [0x3FF]: Name of xmt file: fps117.data Sending Open Server Request. Sending Bind request link 1 Received RDR_BIND_ACK .........................................................

Run the Full Duplex Radar Test Program


To run the read/write radar test program, you must connect a loopback cable between two serial links. Two copies of rdrtest should be run; each reading and writing from the links that are connected to each other. If you have a LAN-based server, power it on and wait for it to download. If you have an embedded server, load it using the commload utility. (Download procedures are described in the MPS Software and Hardware Install Guide.) Start the two rdrtest programs in separate windows with the same protocol specified. The example shown below will configure link 0 for the Toshiba protocol. It will transmit the Makefile, and receive any data coming into the link to the file called foo. This will use the default values for the server name, controller number, baud rate and frame size.
rdrtest -p toshiba -l 0 -x rdrtest.c -r foo1 rdrtest -p toshiba -l 1 -x rdrtest.c -r foo2

rdrtest will prompt you for link configuration information. Once all the link configuration parameters have been specified, the radar test program will open to the radar multiplexor (rdrmux). If the program was compiled to not use the Radar Daemon, it will then open to the specified protocol (in this case Toshiba), link it under the radar multiplexor, and attach it to the physical link. Next the program will bind the link with the desired configuration parameters. At this point, the program is ready to transmit and receive data.

114

Run the Full Duplex Radar Test Program

The radar test program will enter an endless while-loop in which it will read any receive data available (uses MPSpoll() to ensure the call to MPSgetmsg() does not block). It will also transmit the data specified in the file when no reading can be performed. When a message block is received, an r is printed. When a message block is transmitted, an x is printed. Any NULL message indicators will be printed as well. This process is continues until you terminate the program by typing a CTRL-C. Before rdrtest terminates it requests and displays the statistics from RDR for the serial link it was specified.

rdrtest Example
A sample execution of rdrtest is shown below, demonstrating responses to its interactive prompts.
$ rdrtest -b 19200 -f 256 -p thompcsf -l 0 -x rdrtest.c -r foo rdrtest link parameters: -----------------------Link: 0 Baud Rate: 19200 Frame Size: 256 Server: /dev/ucsclone Service: mps Controller: 0 Protocol: thompcsf Transmit File: rdrtest Receive File: foo

Which variant of Thompson? ---------------------------0) TCSF 1) TVT2 Choice [0]: Open Radar Mux. Open to protocol thompcsf Link protocol to rdrmux Close protocol stream. Sending ATTACH Sending Bind request link 0 Received RDR_BIND_ACK Received RDR_OK_ACK to RDR_CLEAR_TICK Ready ????? rxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrx rxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrx rxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrx rxrxrxrxrxrxrxxxxxxxxrxrxrxxxxxxxrxrxrxrxrxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxrxrxrxrxrxrxrxrxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

115

Chapter 5: Sample Test Programs

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr rrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr rrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr rrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr rrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrNull message received on link 0 rNull message received on link 0 rNull message received on link 0 rNull message received on link 0 ^Cr **** Protocol Statistics **** Link 0 (thompcsf) recv_msgs: 483 xmit_msgs: 483 recv_2big: 0 xmit_2big: 0 recv_orun: 0 no_timers: 0 no_buffers: 0 bad_bcc: 0 bad_mtype: 0 no_clocks: 0

Sending Unbind request link 1 Received RDR_OK_ACK to RDR_UNBIND_REQ Detach link request Unlink protocol module from stream End rdrtest test program.

116