Radar Receiver Manual

Radar ReceiverUser’s Guide

w w w. p t . c o m205 Indigo Creek Drive Rochester, NY 14626 Phone +1.585.256.0200 [email protected]

Document Revision History

Copyright Notice

PT is a trademark of Performance Technologies, Inc.

© Copyright 2011 by PT. All Rights Reserved.

Part Number Date Explanation of changes106p0900.10 05/28/98 Initial Release

106p0900.20 09/30/98 New Feature

106p0900.30 09/07/99 Added TPS-75 Protocol

106p0900.31 01/10/01 Update to Idle non 8-bit pattern and Modem Status Notification

106p0900.32 03/07/01 Document new functionality in RDR_ERROR_IND

106p0900.33 09/09/02 Reformatting All

106p0900.40 01/29/03 Added TPS43C protocol information, Chapter 4, Control Primitives

106p0900.41 07/09/03 Multiple Updates

106p0900.50 10/17/03 Added tps43_D Protocol information

106p0900.51 02/09/04 Added cd_bind_req_t structure modifications and definitions. Modified data format for CD-2, Chapter 4

106p0900.52 03/26/04 Added/changed as_bind_req_t, tc_bind_req_t, and cd_bind_req_t structure modifications and definitions, Chapter 4

106p0900.53 07/29/04 tc_bind_req_t, and cd_bind_req_t structure modifications and definitions, cd_encoding definitions and tc_encoding definitions Added Raduga-2 Protocol

106p0900.54 09/21/04 Added Programmable Physical Interface for CPC358 information to Sample Test Programs. Chapter 5, Sample Test Programs

106p0900.55 01/31/05 Modified cd_purge_committed_data definition, Chapter 4

106p0900.56 06/08/06

106p0900.60 02/16/07

106p0900.61 08/03/07 Add support to specify using external clock source for timestamps.Add support to setup optional transmit data acknowledgement timestamps and data.

106p0900.62 10/26/07 Corrected RDR_CLEAR_TICK, RDR_DATA_ACK, RDR_ERROR_ACK, WANSTRPROT_TS_CLOCK_INACCURATE, cd_bind_req_t structure. Reformatted book.

106p0900.63 3/17/08 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.

106p0900.64 07/16/10 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.

106p0900.65 10/19/11 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.

2

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.

3

http://www.pt.com

: http://pt.com/assets/lib/files/pdfs/rohs/policies/rohs-weee-statement.pdf

4

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

5

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


RDR_BIND_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

New State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49


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


RDR_OK_ACK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

6

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

7

Contents


CD_STATISTICS_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

New State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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


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

8

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

9

Contents


AS_DATA_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

New State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83


TC_DATA_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

New State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86


TP_DATA_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

New State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89


RADUGA2_DATA_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

New State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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

13

Chapter 1

About This Guide

OverviewThis 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.

Chapter 1: About This Guide

Text ConventionsThis guide uses the following conventions:

Customer Support and ServicesPT 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).

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.

Convention What it is Used For

Monospace font Monospace font is used to represent sample code.

Bold font 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 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 Regular font is used for the ENTER and TAB keys and the SPACEBAR on your keyboard.

PT Support Contact Information

Embedded Systems and Software(Includes Platforms, Blades, and Servers)

SS7 Systems(Includes SEGway™)

Email [email protected] [email protected]

Phone+1 (585) 256-0248 (Monday to Friday, 8 a.m. to 8 p.m. Eastern Time)

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

14

Product Warranty

Customer Support PackagesOur 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 SupportSupport 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 WarrantyPT warrants that its products sold hereunder will at the time of shipment be free from defects in material and workmanship and will conform to PT’s applicable specifications or, if appropriate, to Buyer’s 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 PT’s 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

http://www.pt.com/page/support/

http://www.pt.com

http://www.pt.com

http://pt.com/assets/lib/files/rma-request-form.doc

Chapter 1: About This Guide

16

17

Chapter 2

Introduction to Radar Receiver

OverviewThis document describes the programming interface to PT’s 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 FormatsThe 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.

Chapter 2: Introduction to Radar Receiver

Application Programming InterfaceApplications 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 API’s protocol messages.

Radar Receiver primitives are sent and received using the API’s 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 User’s Manual for more information on the API.

System ConfigurationThe 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 ServicesBefore 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

Radar Mux

Radar (CD2)Module

Radar Edit(TCSF)

Module

ASTERIXModule

Radar (TCSF)Module

Bit StreamReceiver

Bit StreamReceiver

HDLC Driver

Connec�on todaemon process

Connec�onsto applica�on

Link 0 Link 1 Link 2

One controllingconnec�on

One connec�onor “stream” perlink

20

21

Chapter 3

Radar Daemon Process

OverviewThe 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.


• “Configuration File Format,” on page 21

• “Running the Radar Daemon,” on page 23

Configuration File FormatThe 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.

Chapter 3: Radar Daemon Process

• The keywords and valid parameter values are listed below.

link specifies the serial line, numbered from zero. (The maximum valid link number depends on the hardware platform.)

protocol determines the radar data format to be used. Valid protocol names are shown in Table 3-1: “Valid Protocols”:

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

link 0protocol marconi10

link 1protocol asterix

link 2protocol asterix

link 3protocol cd2

Table 3-1: Valid Protocols

Radar Data Format ProtocolCD-2 cd2

FPS 117 cd2

Marconi 10-Bit marconi10

ASTERIX asterix

Thompson-CSF thompcsf

Thompson-TVT2 thompcsf

Toshiba toshiba

TPS-43 tps43

Modified Eurocontrol euro

General 18-Bit gen18

NEC Radar Extractor nec

TPS-75 tps75

Raduga-2 raduga-2

22

Running the Radar Daemon

Running the Radar DaemonThe 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.

-v This option causes the daemon to print status information as it configures and initializes the Radar Receiver.

-s server 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.

-c controller This parameter specifies the controller number. If not specified, controller defaults to 0.

23

Chapter 3: Radar Daemon Process

24

25

Chapter 4

Control Primitives

OverviewThis 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.


• “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

Chapter 4: Control Primitives

RDR PrimitivesAll 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”:

• 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-1: RDR Primitives Used to Transmit Radar Data on a Serial Link

Radar Data Format RDR Primitive UsedCD-2 (FPS 117) CD_DATA_REQ

Marconi 10-Bit CD_DATA_REQ

ASTERIX AS_DATA_REQ

Thompson-CSF TC_DATA_REQ

Thompson-TVT2 TC_DATA_REQ

Toshiba TC_DATA_REQ

TPS-43 TP_DATA_REQ

Modified Eurocontrol CD_DATA_REQ

General 18-Bit CD_DATA_REQ

NEC Radar Extractor CD_DATA_REQ

TPS-75 TP_DATA_REQ

Raduga-2 RADUGA2_DATA_REQ

Table 4-2: RDR Primitives Used to Request Statistics About a Serial Link

Radar Data Format Primitive Used to Request Statistics Primitive That Provides StatisticsCD-2 (FPS 117) CD_STATISTICS_REQ CD_STATISTICS_ACK

Marconi 10-Bit CD_STATISTICS_REQ CD_STATISTICS_ACK

ASTERIX AS_STATISTICS_REQ AS_STATISTICS_ACK

Thompson-CSF TC_STATISTICS_REQ TC_STATISTICS_ACK

Thompson-TVT2 TC_STATISTICS_REQ TC_STATISTICS_ACK

26

RDR_ATTACH_REQ

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_REQTo 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 API’s 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 FormatThe 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.

Toshiba TC_STATISTICS_REQ TC_STATISTICS_ACK

TPS-43 TP_STATISTICS_REQ TP_STATISTICS_ACK

Modified Eurocontrol CD_STATISTICS_REQ CD_STATISTICS_ACK

General 18-Bit CD_STATISTICS_REQ CD_STATISTICS_ACK

NEC Radar Extractor CD_STATISTICS_REQ CD_STATISTICS_ACK

TPS-75 TP_STATISTICS_REQ TP_STATISTICS_ACK

Raduga-2 RADUGA2_STATISTICS_REQ RADUGA2_STATISTICS_ACK

Table 4-2: RDR Primitives Used to Request Statistics About a Serial Link

27


Parametersrdr_primitive conveys RDR_ATTACH_REQ.

rdr_link 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.)

rdr_l_index must specify the link ID that was returned from the MPSioctl X_LINK request.

rdr_protocol is an ASCII string identifying the radar data format associated with the connection, as follows:

“cd2” CD-2 or FPS 117

“marconi10” Marconi 10-Bit

“asterix” ASTERIX

“thompcsf” Thompson-CSF

“thompcsf” Thompson-TVT2

“toshiba” Toshiba

“tps43” TPS-43

“euro” Modified Eurocontrol

“gen18” General 18-Bit

“nec” NEC Radar Extractor

“tps75” TPS-75

“raduga2” Raduga-2

StateThis message is valid in state RDR_NOTATTACHED.

New StateThe resulting state is RDR_ATTACH_PENDING.

ResponseWhen 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 FailureRDR_ATTACHED Requested physical link is already attached.

RDR_NOSUCHPROTOCOL rdr_protocol string is invalid.

RDR_NOTAUTHOR Link ID specified in rdr_l_index is invalid.

RDR_DETACH_REQThis 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 FormatThe control part of the message is defined by the following structure:

typedef struct{

bit32 rdr_primitive;bit32 rdr_link;

} rdr_primitive;


Parametersrdr_primitive conveys RDR_DETACH_REQ.

rdr_link specifies the serial link to be detached.

StateThis message is valid in state RDR_UNBOUND or RDR_DATAXFER.

New StateThe resulting state is RDR_DETACH_PENDING.

ResponseIn 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


Reasons for FailureRDR_INVALIDPORT The link number specified in rdr_link is invalid.

RDR_BIND_REQThis 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.


typedef struct{

bit32 rdr_primitive;bit32 rdr_link;char rdr_protocol[24];bit32 rdr_max_messages;bit32 rdr_message_timeout;wanStrProt_txDataAcks_t rdr_data_acks;wanStrProt_options1_t rdr_options1;

} rdr_bind_req_t;

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 cd_primitive;bit32 cd_link;bit32 cd_baud;bit32 cd_timeout_baud;bit32 cd_packmesg;bit32 cd_maxmesg_size;bit32 cd_maxmesg_cnt;bit32 cd_fwd_time;bit32 cd_dma_blocksize;bit32 cd_contype;bit32 cd_sync;bit32 cd_invert;bit32 cd_do_idle;bit32 cd_idle_pattern;bit32 cd_modem_in;bit32 cd_sigtimeout;wanStrProt_phyIf_t phyIf;bit32 cd_xmt_unpackmesg;bit32 cd_xmt_idles;bit32 cd_purge_committed_data;wanStrC_serRxTxEncode_t cd_encoding; bit32 cd_idle_buf_to;

} cd_bind_req_t;

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 as_link;bit32 as_framesize;bit32 as_baud;bit32 as_encoding;bit32 as_mode;bit32 as_modem;dlpiAst_phyIf_t phyIf;wanStrProt_txDataAcks_t as_data_acks;bit32 as_purge_committed_data;

31


bit32 as_timeout_baud;bit32 as_fwd_time;

} as_bind_req_t;

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 tc_primitive;bit32 tc_link;bit32 tc_baud;bit32 tc_timeout_baud;bit32 tc_maxmesg_size;bit32 tc_maxmesg_cnt;bit32 tc_fwd_time;bit32 tc_dma_blocksize;bit32 tc_contype;bit32 tc_sync;bit32 tc_check_crc;bit32 tc_time_delay;bit32 tc_variant;bit32 tc_modem_in; bit32 tc_sigtimeout;wanStrProt_phyIf_t phyIf;bit32 tc_purge_committed_data;wanStrC_serRxTxEncode_t tc_encoding; bit32 tc_idle_buf_to;

} tc_bind_req_t;

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 tp_primitive;bit32 tp_link;bit32 tp_baud;bit32 tp_timeout_baud;bit32 tp_maxmesg_size;bit32 tp_maxmesg_cnt;bit32 tp_fwd_time;bit32 tp_dma_blocksize;bit32 tp_contype;bit32 tp_sync;bit32 tp_idle;bit32 tp_modem_in;bit32 tp_sigtimeout;bit32 tp_relaxed_data_gathering;wanStrProt_phyIf_t phyIf;bit32 tp_error_info;bit32 tp_purge_committed_data;wanStrC_serRxTxEncode_t tp_encoding; bit32 tp_idle_buf_to;bit32 tp_enhanced

} tp_bind_req_t;

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

33


Raduga-2 Data Part

For Raduga-2, the data part is defined as follows:

typedef struct{

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

} raduga2_bind_req_t;

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 conveys RDR_BIND_REQ.

rdr_link 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.)

rdr_protocol is an ASCII string identifying the radar data format configured for the associated serial link, as follows:

“cd2” CD-2 or FPS 117

“marconi10” Marconi 10-Bit

“asterix” ASTERIX

“thompcsf” Thompson-CSF

34

RDR_BIND_REQ

“thompcsf” Thompson-TVT2

“toshiba” Toshiba

“tps43” TPS-43

“euro” Modified Eurocontrol

“gen18” General 18-Bit

“nec” NEC Radar Extractor

“tps75” TPS-75

“raduga2” Raduga-2

rdr_max_messages 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_timeoutspecifies 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


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 not used.

cd_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.

cd_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.

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.

cd_packmesg 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.

36

RDR_BIND_REQ

1 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.

cd_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.

cd_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 cd_maxmesg_cnt has not been reached.

cd_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.)

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).

cd_sync 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.

cd_invert configures the link for data bit inversion, as follows:

0 No inversion

1 Invert data bits

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


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.

cd_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.

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.

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 WANSTRPROT_PHYIF_V11 or 0

RS530A WANSTRPROT _PHYIF_RS530A or 1

RS530 WANSTRPROT _PHYIF_RS530 or 2

X.21 WANSTRPROT _PHYIF_X21 or 3

V.35 WANSTRPROT _PHYIF_V35 or 4



HIZ WANSTRPROT _PHYIF_HIZ or 7

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.

1 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 13-bit 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

1 Insert idle words between messages to be transmitted.

cd_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 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.

as_framesize configures the maximum size of an ASTERIX message.

as_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).


as_encoding data encoding for the link as follows:

0 NRZ

1 NRZI

2 FM0 for RAMP Radar (QUICC platform only)

39


3 FM1 (QUICC platforms only)

4 Manchester (QUICC platforms only)

5 Differential Manchester (QUICC platforms only)

as_mode must be set to 0.

as_modem determines whether the serial device driver requires the clear to send (CTS) and data carrier detect (DCD) modem signals, as follows:

1 Link initialization fails if the device driver does not detect CTS and DCD within 90 seconds.

0 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.


V. 11 DLPIAST_PHYIF_V11 or 0

RS530A DLPIAST_PHYIF_RS530A or 1

RS530 DLPIAST_PHYIF_RS530 or 2

X.21 DLPIAST_PHYIF_X21 or 3

V.35 DLPIAST_PHYIF_V35 or 4



HIZ DLPIAST_PHYIF_HIZ or 7

as_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)

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 BD’s 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.

as_fwd_time 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.

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 not used.

tc_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.

tc_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).


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.

tc_maxmesg_size specifies the maximum length of a received Thompson-CSF, Thompson-TVT2 or a Toshiba radar message, in bytes.

41


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.

tc_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 tc_maxmesg_cnt has not been reached.

tc_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.


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).

tc_sync specifies the hexadecimal value of the sync character; 0x32 for Thompson-CSF and Toshiba, and 0x16 for Thompson-TVT2.

tc_check_crc configures CRC checking for received messages as follows:

0 Ignore CRC

1 Discard messages with CRC errors

tc_time_delay 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.

tc_variant specifies the type of Thompson radar format (not used by Toshiba) as follows:

42

RDR_BIND_REQ

THOMP_A Thompson-CSF

THOMP_B Thompson-TVT2

tc_modem_in specifies how the SBSI driver should handle changes in modem input signals during link operation:


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.


V. 11 DLPIAST_PHYIF_V11 or 0

RS530A DLPIAST_PHYIF_RS530A or 1


X.21 DLPIAST_PHYIF_X21 or 3

V.35 DLPIAST_PHYIF_V35 or 4



HIZ DLPIAST_PHYIF_HIZ or 7

tc_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 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:



43



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.


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.

tp_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.

tp_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).


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.

tp_maxmesg_size 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.

tp_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.

tp_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 tp_maxmesg_cnt has not been reached.

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.


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).

tp_sync 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).

tp_idle 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).

tp_modem_in specifies how the SBSI driver should handle changes in modem input signals during link operation:



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_gatheringspecifies that unparsed data including SOM be sent up to client application (0 - off, 1 - on).








45




tp_error_info 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 BD’s 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:




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.


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_sizespecifies 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.


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).

raduga2_sync specifies the hexadecimal value of the start group. This would be the Barker Code (0x712) for Raduga-2 messages.

raduga2_check_crc at this moment, not used.

raduga2_check_parity at this moment, not used.

47


raduga2_modem_in specifies how the SBSI driver should handle changes in modem input signals during link operation:



raduga2_sigtimeoutspecifies 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_patternuser 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).










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_toThis 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.


StateThis message is valid in state RDR_UNBOUND.

New StateThe resulting state is RDR_BIND_PENDING.

ResponseWhen 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


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 FailureRDR_DLSAP_IN_USE The requested DLSAP is already bound to another

connection.

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

RDR_NOSUCHPROTOCOL The rdr_protocol string is invalid.

RDR_INVALID_BIND_PARAMS Either the control part or data part Bind parameters structure is not of valid format.

RDR_NOFREEUSCB RDR cannot obtain the system resources necessary to complete the bind request.

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

50

RDR_BIND_ACK

RDR_BIND_ACKThis 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.


typedef struct{


} rdr_bind_ack_t;


Parametersrdr_primitive conveys RDR_BIND_ACK.

rdr_link identifies the DLSAP that was bound.

StateThis message is valid in state RDR_BIND_PENDING.

New StateThe resulting state is RDR_DATAXFER.

51


RDR_UNBIND_REQThis 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.


typedef struct{


} rdr_primitive;


Parametersrdr_primitive conveys RDR_UNBIND_REQ.

rdr_link identifies the DLSAP.

StateThis message is valid in state RDR_DATAXFER.

New StateThe resulting state is RDR_UNBIND_PENDING.

ResponseIn 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 FailureRDR_NOTINIT The specified DLSAP is not currently bound to the connection.

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

52

RDR_OK_ACK

RDR_OK_ACKThis 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.


typedef struct{

bit32 rdr_primitive;bit32 rdr_correct_primitive;bit32 rdr_modifier;

} rdr_ok_ack_t;


Parametersrdr_primitive conveys RDR_OK_ACK.

rdr_correct_primitiveidentifies the successfully received primitive that is being acknowledged.

rdr_modifier identifies the DLSAP.

StateThis 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 StateThe resulting state depends on the state from which the primitive was issued.

53


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


typedef struct{

bit32 rdr_primitive;bit32 rdr_link;bit32 rdr_timestamp;struct utimeval rdr_sntp_timestamp;wanStrPro_timeStatus_t rdr_timeStatus;

} rdr_data_ack_t;

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.

Parametersrdr_primitive conveys RDR_DATA_ACK.


rdr_timestamp 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 clock’s internal oscillator is not accurate and could indicate a hardware problem.

StateThis 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 StateThe resulting state depends on the state from which the primitive was issued.

55


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


typedef struct{

bit32 rdr_primitive;bit32 rdr_error_primitive;bit32 rdr_errno;bit32 rdr_modifier;bit32 rdr_timestamp;struct utimeval rdr_sntp_timestamp;wanStrPro_timeStatus_t rdr_timeStatus;

} rdr_error_ack_t;

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.

Parametersrdr_primitive conveys RDR_ERROR_ACK.

rdr_error_primitiveidentifies the primitive in error.

rdr_errno conveys the DLPI error code associated with the failure. See the individual primitive for the error codes that are applicable.

rdr_modifier identifies the DLSAP.

rdr_timestamp 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







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

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

57


RDR_REISSUE_STARTThis 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.


typedef struct{


} rdr_primitive;


Parametersrdr_primitive conveys RDR_BIND_ACK.

rdr_link identifies the DLSAP that was bound.

StateThis message is valid in state RDR_BIND_PENDING.

New StateThe resulting state is unchanged.

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

Reasons for FailureRDR_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_INDThis 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.


typedef struct{

bit32 rdr_primitive;bit32 rdr_link;bit32 rdr_errno;

} rdr_error_ind_t;


Parametersrdr_primitive conveys RDR_ERROR_IND.


rdr_errno 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.

CD_ECOMM 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 CD-2 (FPS 117), Marconi 10-Bit, Modified Eurocontrol or General 18-Bit.

TC_EMSGSIZE 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.

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

59


AS_LINKDOWN The receiver has lost link (connection) on the serial link.

AS_LINKUP The receiver has a link condition (connection) on the serial link.

RDR_CTS_UP “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.

RDR_CTS_DOWN “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.

RDR_BAD_MARKBITindicates a protocol message failed a mark bit test and will be discarded. Setting the tp_error_info parameter enables this message.

RDR_BAD_CRC indicates a protocol message failed a crc test and will be discarded. Setting the tp_error_info parameter enables this message.

RDR_DCD_UP “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.

RDR_DCD_DOWN “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.



60

RDR_CLEAR_TICK

RDR_CLEAR_TICKAn 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.


typedef struct{


} rdr_primitive;


Parametersrdr_primitive conveys RDR_CLEAR_TICK.


StateThis message is valid in any state.


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

Reasons for FailureRDR_INVALIDPORT The specified DLSAP is invalid (out of range).

61


CD_STATISTICS_REQAn 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.


typedef struct{


} rdr_primitive;


Parametersrdr_primitive conveys CD_STATISTICS_REQ.

rdr_link identifies the serial link (DLSAP) for which statistical information is requested.



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


62

CD_STATISTICS_ACK

CD_STATISTICS_ACKRDR sends this message in response to CD_STATISTICS_REQ.


typedef struct{


} 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 conveys CD_STATISTICS_ACK.

rdr_link identifies the DLSAP to which the statistical information applies.

63


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 total number of received messages since the connection was established.

cd_recv_2big number of times the maximum message size configured for the connection was exceeded.

cd_sync_lost number of times synchronization on the serial link was lost.

cd_recv_orun number of receive overruns.

cd_no_timers number of times the data-forwarding timer could not be initiated due to a shortage of system resources.

cd_no_buffers number of times the radar protocol module was required to retry an attempt to obtain a data buffer for received data.

cd_bad_mtype number of unrecognized message types (non-protocol messages) received from the connected application.

cd_recv_borun number of received data buffers overwritten due to lack of memory resources.

cd_xmit_msgs total number of messages transmitted since the connection was established (diagnostic connection only).

cd_no_clocks number of times the serial device driver failed to forward any data (due to lack of clocks).

cd_data_acks total number of data acknowledgements received in response to a DATA_REQ primitive.



64

AS_STATISTICS_REQ

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


typedef struct{


} rdr_primitive;


Parametersrdr_primitive conveys AS_STATISTICS_REQ.




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


65


AS_STATISTICS_ACKRDR sends this message in response to AS_STATISTICS_REQ.


typedef struct{


} rdr_primitive;



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 conveys AS_STATISTICS_ACK.


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 total number of received messages since the connection was established.

as_xunder number of transmit underruns.

as_rover number of receive overruns.

as_rtoo number of times the maximum message size configured for the connection was exceeded.

as_rcrc number of CRC (frame check sequence) errors.

as_rabt number of aborted frames.

as_no_clocks number of times the serial device driver failed to forward any data (due to lack of clocks).

as_data_acks total number of data acknowledgements receieved in response to a DATA_REQ primitive.

as_corrupt_msgs number of corrupt messages transmitted. This occurs if the message was not completely transmitted due to an error.



67


TC_STATISTICS_REQAn 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.


typedef struct{


} rdr_primitive;


Parametersrdr_primitive conveys TC_STATISTICS_REQ.




ResponseRDR 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_ACKRDR sends this message in response to TC_STATISTICS_ACK.


typedef struct{


} rdr_primitive;



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 conveys TC_STATISTICS_REQ.


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


tc_recv_msgs total number of received messages since the connection was established.

tc_xmit_msgs total number of messages transmitted since the connection was established.

tc_recv_2big number of times the maximum receive message size configured for the connection was exceeded.

tc_xmit_2big number of times the maximum transmit message size configured for the connection was exceeded.

tc_recv_orun number of receive overruns.

tc_no_timers number of times the data-forwarding timer could not be initiated due to a shortage of system resources.

tc_no_buffers number of times received data was discarded because memory was not available.

tc_bad_bcc number of messages discarded due to block check errors.

tc_bad_mtype number of unrecognized message types (non-protocol messages) received from the connected application.

tc_recv_borun number of received data buffers overwritten due to lack of memory resources

tc_no_clocks number of times the serial device driver failed to forward any data (due to lack of clocks).

tc_data_acks total number of data acknowledgements received in response to DATA_REQ primitive.



70

TP_STATISTICS_REQ

TP_STATISTICS_REQAn 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.


typedef struct{


} rdr_primitive;


Parametersrdr_primitive conveys TP_STATISTICS_REQ.




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

71


TP_STATISTICS_ACKRDR sends this message in response to TP_STATISTICS_ACK.


typedef struct{


} rdr_primitive;



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 conveys TP_STATISTICS_REQ.


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 total number of received messages since the connection was established.

tp_xmit_msgs total number of messages transmitted since the connection was established.

tp_recv_2big number of times the maximum receive message size configured for the connection was exceeded.

tp_xmit_2big number of times the maximum transmit message size configured for the connection was exceeded.

tp_recv_orun number of receive overruns.

tp_no_timers number of times the data-forwarding timer could not be initiated due to a shortage of system resources.

tp_no_buffers number of times received data was discarded because memory was not available.

tp_bad_mtype number of unrecognized message types (non-protocol messages) received from the connected application.

tp_recv_borun number of received data buffers overwritten due to lack of memory resources.

tp_bad_parity number of received messages discarded due to parity errors or mark bit errors (if TPS43_B, TPS43_C, TPS43_D or TPS-75).

tp_xmt_rjct number of transmitted messages discarded due to the message size not being an even multiple of the data size.

tp_no_clocks number of times the serial device driver failed to forward any data (due to lack of clocks).

tp_data_acks total number of data acknowledgements received in response to a DATA_REQ primitive.

tp_bad_mbit number of transmit messages discarded due to the final mark bit not being set.



73


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


typedef struct{bit32 rdr_primitive;bit32 rdr_link;} rdr_primitive;


Parametersrdr_primitive conveys RADUGA2_STATISTICS_REQ.




ResponseRDR 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_ACKRDR sends this message in response to RADUGA2_STATISTICS_ACK.


typedef struct{bit32 rdr_primitive;bit32 rdr_link;} rdr_primitive;



typedef struct{

bit32 raduga2_recv_msgs; /* Total messages received */bit32 raduga2_xmit_msgs; /* Total xmt messages */bit32 raduga2_recv_2big; /* Recv messages too big */bit32 raduga2_xmit_2big; /* Xmit message too big */bit32 raduga2_recv_orun; /* Receive overruns */bit32 raduga2_no_timers; /* Forward timer failures */bit32 raduga2_no_buffers; /* Buffer alloc failures */bit32 raduga2_bad_mtype; /* Unknown STREAMS type */bit32 raduga2_recv_borun; /* Receive buffer overruns */bit32 raduga2_no_clocks; /* No data due to no clocks */bit32 raduga2_data_acks; /* # Data Acks sent up stream */bit32 raduga2_num_parity; /* # Message parity errors */bit32 raduga2_bad_msg_lngth; /* # Message Length errors */bit32 raduga2_num_crc; /* # CRC (Control Pattern) errors */bit32 raduga2_bad_mark_bit; /* # Mark bit errors */bit32 raduga2_xmit_rjct; /* # Transmit Data Req rejected. */

} raduga2_statistics_t;

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

Parameters



rdr_primitive conveys RADUGA2_STATISTICS_REQ.

75



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_buffersnumber 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_borunnumber 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_paritynumber 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_bitnumber of received messages discarded due to mark bit errors

raduga2_xmt_rjct currently not used.

76

RADUGA2_STATISTICS_ACK



77


CD_DATA_REQAn 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.


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.

Parameterscd_primitive conveys CD_DATA_REQ.

cd_link identifies the serial link (DLSAP) on which the block of data is to be transmitted.

cd_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.

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 least-significant 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.

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 most-significant bit of the word in upper case. The zero value indicates unused.

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 least-significant bits of the second byte contain the six least-significant bits of the second word, and so on.

Byte 1 Byte 2 Byte 3 Byte 4Aaaaaaaa aaaaaBbb bbbbbbbb bbCccccc

Byte 1 Byte 2 Byte 3 Byte 4000Aaaaa aaaaaaaa 000Bbbbb bbbbbbbb

79


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.

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.

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 least-significant bits of the third byte contain the six most-significant bits of the second word, and so on.

Byte 1 Byte 2 Byte 3 Byte 4aaaaaaaa aAbbbbbb bbbBcccc cccccCdd

Byte 1 Byte 2 Byte 3 Byte 4000000aa aaaaaaaA 000000bb bbbbbbbB

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.

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.

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 Byte 2 Byte 3 Byte 4 Byte5Aaaaaaaa aaaaaaaa aaBbbbbb bbbbbbbb bbbbCccc

Byte 1 Byte 2 Byte 3 Byte 400000000 000000Aa aaaaaaaa aaaaaaaa

Byte 1 Byte 2 Byte 3 Byte N1aaaaaaa Bbbbbbbb Cccccccc ... 00000000

81



ResponseThere 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 FailureENOLINK No DLSAP is bound to the connection.

EACCESS The connection is not configured for diagnostic mode.

RDR_DATA_TIMEDOUT Failed to transmit message before timeout value.

RDR_BAD_DATA_FORMAT The control structure is not of valid format.

RDR_BAD_DATA_BLOCK The data part of the request does not exist.

AS_DATA_REQAn 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.


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.

Parametersas_primitive conveys AS_DATA_REQ.

as_link 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.





RDR_DATA_TIMEDOUT Failed to transmit message before timedout value.

83


TC_DATA_REQAn 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.


• A DLE-ETX control sequence is added at the end of the data. In this case, ETX has the value 0x83.


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.


• A DLE-ETX control sequence is added at the end of the data.


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


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.

Parameterstc_primitive conveys TC_DATA_REQ.

tc_link identifies the serial link (DLSAP) on which the block of data is to be transmitted.

tc_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.

tc_hdr1 contains the value to be transmitted in the first byte of the two-byte header. For Toshiba Radar, this value is not used.

tc_hdr2 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 Byte 2 Byte 3 Byte 41aaaaaaa Bbbbbbbb Cccccccc Dddddddd

85


ResponseThere 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.






86

TP_DATA_REQ

TP_DATA_REQAn 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 zero’s 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:


• 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


TPS-75

For a TPS-75 radar message, the RDR formats a radar message for transmission as follows:


• 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).


typedef struct{

bit32 tp_primitive;bit32 tp_link;bit32 tp_noclock_to;

} tp_data_req_t;


Parameterstp_primitive conveys TP_DATA_REQ.

tp_link identifies the serial link (DLSAP) on which the block of data is to be transmitted.

tp_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.

88

TP_DATA_REQ









89


RADUGA2_DATA_REQAn 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.


typedef struct{ bit32 raduga2_primitive; bit32 raduga2_link; bit32 raduga2_noclock_to; bit32 raduga2_message_length; bit32 raduga2_message_identifier;} raduga2_data_req_t;


Parametersraduga2_primitive conveys RADUGA2_DATA_REQ.

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

raduga2_noclock_toapplies 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_lengthconveys 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_identifierconveys 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









91


RDR_DATA_INDWhen 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.


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 cd_link;bit32 cd_time_stamp;struct utimeval cd_sntp_time_stamp;wanStrProt_timeStatus_t cd_timeStatus;bit32 cd_length;bit32 cd_idles;

} cd_message;

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 as_link;bit32 as_time_stamp;struct utimeval as_sntp_time_stamp;wanStrProt_timeStatus_t as_timeStatus;bit32 as_length;bit32 as_reserved;

} as_message;

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 tc_link;bit32 tc_time_stamp;struct utimeval tc_sntp_time_stamp;wanStrProt_timeStatus_t tc_timeStatus;bit32 tc_length;bit8 tc_hdr1;bit8 tc_hdr2;bit16 tc_reserved;

} tc_message;

93


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 tp_link;bit32 tp_time_stamp;struct utimeval tp_sntp_time_stamp;wanStrProt_timeStatus_t tp_timeStatus;bit32 tp_length;bit32 tp_reserved;

} tp_message;

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 raduga2_link; bit32 raduga2_time_stamp; struct utimeval raduga2_sntp_time_stamp;

wanStrProt_timeStatus_t raduga2_timeStatus; bit32 raduga2_length; raduga2_info_t raduga2_info; bit16 raduga2_reserved;} raduga2_message;

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 conveys RDR_DATA_IND.

rdr_reason 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 identifies the serial link on which the message was received (and indirectly identifies the radar data format).

cd_time_stamp contains the time stamp (tick count), recorded at the time the first byte of the message was received.

cd_sntp_time_stampcontains 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:







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.

cd_idles 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.

95


as_message RMH Structure Parameters

In the as_message RMH structure:

as_link identifies the serial link on which the message was received (and indirectly identifies the radar data format).

as_time_stamp contains the time stamp (tick count), recorded at the time the first byte of the message was received.

as_sntp_time_stampcontains 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:







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.

as_reserved is not used.

tc_message RMH Structure Parameters

In the tc_message RMH structure:

tc_link identifies the serial link on which the message was received.

tc_time_stamp 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_stampcontains 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:







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.

tc_hdr1 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.

tc_hdr2 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.

tc_reserved is not used.

tp_message RMH Structure Parameters

In the tp_message RMH structure:

tp_link identifies the serial link on which the message was received.

tp_time_stamp contains the time stamp (tick count), recorded at the time the first byte of the message was received.

97


tp_sntp_time_stampcontains 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:






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.

tp_reserved is not used.

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_stampcontains 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_timeStatusspecifies 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






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.

raduga2_info contains the Raduga-2 Message Length and Message Identifier values.

raduga2_reserved is not used.

A Note About ConfigurationWith 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”.

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

Table 4-3: Timeout and Messages Parameters

Module Structure Timeout Parameter Messages ParameterRadar Mux rdr_bind_req_t rdr_message_timeout rdr_max_messages

CD-2, Marconi cd_bind_req_t cd_fwd_time cd_maxmesg_cnt

ASTERIX as_bind_req_t as_fwd_time as_framesize

Thompson-CSF tc_bind_req_t tc_fwd_time tc_maxmesg_cnt

Thompson-TVT2 tc_bind_req_t tc_fwd_time tc_maxmesg_cnt

Toshiba tc_bind_req_t tc_fwd_time tc_maxmesg_cnt

TPS-43 tp_bind_req_t tp_fwd_time tp_maxmesg_cnt

Modified Eurocontrol cd_bind_req_t cd_fwd_time cd_maxmesg_cnt

General 18-Bit cd_bind_req_t cd_fwd_time cd_maxmesg_cnt

NEC Radar Extractor cd_bind_req_t cd_fwd_time cd_maxmesg_cnt

TPS-75 tp_bind_req_t tp_fwd_time tp_maxmesg_cnt

Raduga-2 raduga2_bind_req_t raduga2_fwd_time raduga2_maxmesg_cnt

99


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 Mux’s 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 FormatThe 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 FormatWithin 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).

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.

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).

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 Byte 2 Byte 3 Byte 4Aaaaaaaa aaaaaBbb bbbbbbbb bbCccccc ...

Byte 1 Byte 2 Byte 3 Byte 4000Aaaaa aaaaaaaa 000Bbbbb bbbbbbbb ...

Byte 1 Byte 2 Byte 3 Byte 4Aaaaaaaa aaBbbbbb bbbbCccc ccccccDd ...

Byte 1 Byte 2 Byte 3 Byte 4000000Aa aaaaaaaa 000000Bb bbbbbbbb ...

101


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.

Thompson-CSF, Thompson-TVT2 and Toshiba

Each of the Thompson-CSF, Thompson-TVT2 and Toshiba radar messages consists of a two-byte 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.

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.

Byte 1 Byte 2 Byte 3 Byte 4Aaaaaaaa Bbbbbbbb Cccccccc Dddddddd ...


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).

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.

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.

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 Byte 2 Byte 3 Byte 4 Byte5Aaaaaaaa aaaaaaaa aaBbbbbb bbbbbbbb bbbbCccc ...

Byte 1 Byte 2 Byte 3 Byte 400000000 000000Aa aaaaaaaa aaaaaaaa

Byte 5 Byte 6 Byte 7 Byte 800000000 000000Bb bbbbbbbb bbbbbbbb ...



103


ExampleFigure 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:

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.

Table 4-4: Sample Message Format Configuration

Link Radar Type cd_packmesg Max Message Size0 CD-2 1 12

1 ASTERIX n/a n/a

2 Thompson-CSF n/a 28

3 Marconi 10-Bit 0 24

104

RDR_DATA_IND

Figure 4-1: Sample Message Formats

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.

cd_link = 0cd_time_stamp

cd_length = 9cd_idles

cd_link = 0

cd_time_stampcd_sntp_time_stamp

cd_length = 12

cd_idles

CD-2 Message

cd_link = 3

cd_time_stampcd_sntp_time_stamp

cd_length = 0

cd_idles

cd_sntp_time_stamp

cd_link = 3cd_time_stamp

cd_length = 14cd_idles

cd_sntp_time_stamp

MarconiMessage

unused

CD-2 Message

unused

tc_link = 2

tc_time_stamp

tc_sntp_time_stamptc_length = 18

header reserved

Thompson-CSFMessage Data

unused

Data Part

as_link = 1as_time_stamp

as_sntp_time_stampas_length = 22

as_reserved

ASTERIXMessage

unused

tc_link = 2

tc_time_stamptc_sntp_time_stamp

tc_length = 12

Thompson-CSFMessage Data

unused

header reserved

Message 2Message 1

RDR_DATA_INDDL_TIMEDOUT

rdr_mesg_cnt = 3

RDR_DATA_INDDL_TIMEDOUT

rdr_mesg_cnt = 4

Control Part

105


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.



106

107

Chapter 5

Sample Test Programs

OverviewAs 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.


• “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 ProgramThe 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 ProgramThe 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 ProgramThe 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.

Chapter 5: Sample Test Programs

Test ParametersThe command lines for the three test programs are defined as follows:

rdrxmt [-b baud] [-c controller] [-D acks option] [-i] [-M][-n protocol] [-O timestamps option] [-P physical IF] [-s server] [-T message limit] [-v service] [-w] [-W conntype]

rdrcv [-b baud] [-c controller] [-D dump timestamp to file] [-F][-f SNTP timestamp frequency] [-i] [-m msg_per_block] [-M multicast opt] [-n protocol] [-O timestamps option] [-P physical IF] [-s server] [-S show timestamp] [-t block_timeout] [-v service] [-w] [-W conntype]

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.

-c controller This parameter specifies the controller number. If not specified, controller defaults to 0.

-D acks option 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.

-D dump timestamp to fileFor rdrcv, this parameter specifies that the timestamps that accompany the data are saved off into the file: "./acktest_ts_recv.txt".

-e Asterix encodingSpecific 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 frequencyFor 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.

-i 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.

-l linkno This parameter identifies the serial link that will be associated with the connection. If not specified, the link defaults to 0.

-L For rdrtest only. Continuous transmit of specified send file.

-M multicast opt For rdrcv only. Based on the provided option value, the application willbe configured as follows:MPSMULTICAST_CLIENT_CONTROL_CON (1) Will have the application configure the MPS Server to provide the receive link’s 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.

-m maxcount 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.

-n protocol Opens to the specified protocol without going through the radar multiplexor.

-O timestamps optionSpecifies 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.

-P physical IF 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.

-r rcvfile This parameter specifies the name of the file to receive. This is a required parameter.

109


-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.

-S show timestampFor rdrcv, print detailed timestamp information for each received data message to the standard output.

-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).

-T 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.

-v service 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.

-W conntype 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.

-w 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.

-x xmtfile This parameter specifies the name of the file to transmit. This is a required parameter.

Run the Transmit and Receive Test ProgramsTo 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


3) thompcsf4) euro 5) gen186) toshiba7) tps438) nec9) tps7510) 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) euro5) gen186) toshiba7) tps438) nec9) tps7510) raduga2

protocol [0]: 3Framesize [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) euro5) gen186) toshiba7) tps438) nec9) tps7510) raduga2

protocol [0]: 1 Framesize [256]: 128 Timeout baud [9600]: 4800Reply 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) euro5) gen186) toshiba7) tps438) nec9) tps7510) radagu2

protocol [0]: 2 Framesize [256]: 512Timeout baud [9600]: 2400 Reply timeout [30]: 40

Which data encoding method for ASTERIX?--------------------------------------------0) NRZ1) NRZI2) FM0 for RAMP Radar3) FM14) Manchester5) Differential Manchester

Choice [0]: 0Name of receive file: rcv6 link number (-1 to continue) [-1]:Sending Open Server Request.

M E N UP 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


1) marconi10 2) asterix 3) thompcsf 4) euro5) gen186) toshiba7) tps438) nec9) tps7510) 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 ProgramTo 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 foo1rdrtest -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: 0Baud Rate: 19200Frame Size: 256Server: /dev/ucscloneService: mpsController: 0Protocol: thompcsfTransmit File: rdrtestReceive File: foo

Which variant of Thompson?----------------------------0) TCSF1) TVT2

Choice [0]: Open Radar Mux.Open to protocol thompcsfLink protocol to rdrmuxClose protocol stream.Sending ATTACHSending Bind request link 0Received RDR_BIND_ACKReceived RDR_OK_ACKto RDR_CLEAR_TICKReady ?????rxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxxxxxxxxrxrxrxxxxxxxrxrxrxrxrxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxrxrxrxrxrxrxrxrxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

115


xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrNull message receivedon link 0rNull message received on link 0rNull message received on link 0rNull message received on link 0^Cr

**** Protocol Statistics **** Link 0 (thompcsf)recv_msgs: 483xmit_msgs: 483recv_2big: 0xmit_2big: 0recv_orun: 0no_timers: 0no_buffers: 0bad_bcc: 0bad_mtype: 0no_clocks: 0

Sending Unbind request link 1Received RDR_OK_ACKto RDR_UNBIND_REQDetach link requestUnlink protocol module from stream

End rdrtest test program.

116

Documents

Radar Receiver Manual