Radar Receiver Manual

2007 Performance Technologies, Inc.All Rights Reserved.

Performance Technologies205 Indigo Creek DriveRochester, NY [email protected]

www.pt.com

Radar Receiver

User's Guide

Radar Receiver UserGuide

Document Revision History

Copyright Notice Copyright 2007 by Performance Technologies, Inc. All Rights Reserved.

IPnexus and the Performance Technologies logo are trademarks and registered trademarks of Performance Technologies, Inc.

CompactPCI and PICMG is a registered trademark of the PCI Industrial Computer Manufacturers Group.

All other product and brand names are trademarks or registered trademarks of their respective owners. This document is the sole property of Performance Technologies Inc.

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

DisclaimerThis document presents information for users of Performance Technologies Inc. products. Although the information contained within this document is considered accurate and characteristic of the subject product, Performance Technologies Inc. reserves the right to make changes to this document and any products described herein to improve reliability, functionality, or design. Performance Technologies Inc. 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 Performance Technologies Inc.

TrademarksThis document is the sole property of Performance Technologies Inc. All other brands or names are trademarks of their respective holders.

IPnexus and the Performance Technologies logo are trademarks of Performance Technologies, Inc.

CompactPCI is a registered trademark of the PCI Industrial Computer Manufacturers Group. All other brands or names are trademarks of their respective holders.

Compliance with RoHS and WEEE DirectivesIn 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.

Performance Technologies' complete position statements on the RoHS and WEEE Directives can be viewed on the Web at http://www.pt.com/rohs/position.html.

Errors and OmissionsAlthough 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 Performance Technologies, Inc. Web site to obtain manual revisions or current customer information: http://www.pt.com.

Performance Technologies, Inc., reserves its right to change product specifications without notice. 3

Chapter 1: About This Guide 13

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Text Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Customer Support and Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

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

C o n t e n t s5

Chapter 3: Radar Daemon Process 21

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Configuration File Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Running the Radar Daemon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Chapter 4: Control Primitives 25

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

ContentsRDR Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

RDR_ATTACH_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

New State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Reasons for Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

RDR_DETACH_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

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

Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

New State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30


RDR_BIND_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

New State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50


RDR_BIND_ACK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

New State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

RDR_UNBIND_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

New State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52


ContentsRDR_OK_ACK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

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

Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

New State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

RDR_CLEAR_TICK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

New State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60


CD_STATISTICS_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

New State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61


ContentsCD_STATISTICS_ACK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

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

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

State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

New State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

AS_STATISTICS_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

New State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64


AS_STATISTICS_ACK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

New State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

TC_STATISTICS_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

New State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

TC_STATISTICS_ACK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

New State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

TP_STATISTICS_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

New State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 708

ContentsTP_STATISTICS_ACK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

New State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

RADUGA2_STATISTICS_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

New State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

RADUGA2_STATISTICS_ACK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

New State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

CD_DATA_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

New State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81


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

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

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

State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

New State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

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


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

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

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

State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 859

ContentsNew State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

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


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

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

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

State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

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

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

Test Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10810

ContentsRun the Transmit and Receive Test Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

Run the Full Duplex Radar Test Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

Index 11711

Contents12

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, thereceive radar messages.

Chapter 5, Sample Test Programs on page 107 contains exampleThree test programs are included in source form with the release anClient directory. primitives are used to

s of the interface to RDR. d are located in the Radar 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 C h a p t e r

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

Chapter 1: About This Guide Text ConventionsThis guide uses the following conventions:

Customer Support and ServicesPerformance Technologies 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 Performance Technologies, Inc. product, you may contact our support personnel by:

1. EMAIL (Preferred Method) Email us at [email protected]. Outline your problem in detail. Please include your return email address, and a telephone number.

2. FAX Contact us via fax at the numbers listed below. Mark your Fax Attention: Technical Support. Outline your problem in detail. Please include your return Fax number, telephone number, and email address.

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.

The caution icon indicates information that may prevent loss of data.

The warning icon indicates information that may prevent physical harm to the user or the hardware.14

Product Warranty3. TELEPHONE Contact us via telephone at the numbers listed below, and request Technical Support. Our offices are open between Monday to Friday, 8:00 a.m. and 5:00 p.m. (Eastern Standard Time) and Monday to Friday, 8:00 a.m. and 5:00 p.m. (Pacific Standard Time).

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

To find our more about our Customer Support packages

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

Product WarrantyPerformance Technologies, Incorporated, warrants that its products sold hereunder will at the time of shipment be free from defects in material and workmanship and will conform to Performance Technologies applicable specifications or, if appropriate, to Buyers specifications accepted by Performance Technologies in writing. If products sold hereunder are not as warranted, Performance Technologies 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 Performance Technologies 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 Performance Technologiess 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 Performance Technologies and a statement of the reason for the return. Please contact Performance Technologies, or its agent, with the product serial number to obtain an RMA number. If Performance Technologies determines that the products are not defective, Buyer shall pay Performance Technologies all costs of handling and transportation. This warranty shall not apply to any products Performance Technologies 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.

Performance Technologies Support Contact Numbers

Embedded Systems Embedded Software

Email [email protected] [email protected]

FAX (585) 256-0791(805) 541-5088

(858) 627-1710(585) 256-0791

Phone (585) 256-0248 (M-F, 8 to 5 Eastern) (805) 783-6004 (M-F, 8 to 5 Pacific)

(858) 627-1700 (M-F, 8 to 5 Pacific) (585) 256-0248 (M-F, 8 to 5 Eastern) 15

Chapter 1: About This GuideTHIS WARRANTY IS IN LIEU OF ALL OTHER WARRANTIES WHETHER EXPRESS, IMPLIED OR STATUTORY INCLUDING IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS. IN NO EVENT SHALL PERFORMANCE TECHNOLOGIES BE LIABLE FOR ANY INCIDENTAL OR CONSEQUENTIAL DAMAGES DUE TO BREACH OF THIS WARRANTY OR ANY OTHER OBLIGATION UNDER THIS ORDER OR CONTRACT.16

RDR, Performance Technologies 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 EurocontrolTopics 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 C h a p t e r

2Introduction to Radar Receiver

OverviewThis document describes the programming interface to Performance Technologies Radar Receiver (RDR) software package. This interface is derived from the Data Link Provider Interface Specification published by UNIX International. 17

Chapter 2: Introduction to Radar Receiver 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.

Application Programming InterfaceApplications send and receive DLPI messages using the Performance Technologies Application Programming Interface (API). The API defines two types of messages. Data messages contain only data. Protocol messages contain a control part and, optionally, a data part. All the messages, or primitives, defined by RDR correspond to the APIs protocol messages.

Radar Receiver primitives are sent and received using the APIs MPSputmsg and MPSgetmsg calls. Most primitives have only a control part, which identifies the primitive type and contains associated parameters. Certain control primitives also have a data part, which contains data associated with the primitive.

Refer to the document UNIX/Windows NT Application Programming Interface Users Manual for more information on the API.

System ConfigurationThe Radar Receiver software executes entirely on a Performance Technologies 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.18

Overview of DLPI ServicesNext, 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.

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 ReceiverFigure 2-1: Radar Receiver System Configuration20

protocol name. You should modify one of these configuration files according to your specific site requirements. The format of the configuration file immediately follows. Running the Radar Daemon on page 23 explains how to run the daemon process.

Topics included in this chapter include:

Configuration File Format, on page 22 Running the Radar Daemon, on page 23daemon 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 C h a p t e r

3Radar 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 21

Chapter 3: Radar Daemon ProcessConfiguration 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 28.

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

Table 3-1: Valid Protocols

Radar Data Format Protocol

CD-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-222

Running the Radar Daemonlink 0protocol marconi10

link 1protocol asterix

link 2protocol asterix

link 3protocol cd2

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 Process24

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 58 RDR_CLEAR_TICK on page 60 CD_STATISTICS_REQ on page 61 CD_STATISTICS_ACK on page 62 AS_STATISTICS_REQ on page 64 AS_STATISTICS_ACK on page 65 TC_STATISTICS_REQ on page 67 TC_STATISTICS_ACK on page 68Topics included in this chapter include:

RDR Primitives on page 26 RDR_ATTACH_REQ on page 28 RDR_DETACH_REQ on page 30 RDR_BIND_REQ on page 31 RDR_BIND_ACK on page 51C h a p t e r

4Control 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. 25

Chapter 4: Control Primitives TP_STATISTICS_REQ on page 70 TP_STATISTICS_ACK on page 71 RADUGA2_STATISTICS_REQ on page 73 RADUGA2_STATISTICS_ACK on page 74 CD_DATA_REQ on page 77 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

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:

Table 4-1: RDR Primitives Used to Transmit Radar Data on a Serial Link

Radar Data Format RDR Primitive Used

CD-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_REQ26

RDR Primitives 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:

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.

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 Statistics

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

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

Chapter 4: Control PrimitivesRDR_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 APIs MPSioctl call to send a request of type X_LINK to

the radar mux, linking the protocol connection underneath the radar mux. Send an attach request to the radar mux for each radar protocol connection (one for each physical

link).

The RDR_ATTACH_REQ message is sent by the daemon to request that RDR attach a physical link to the connection. This request informs the radar mux of the protocol type (radar data format) assigned to each of its lower-level streams.

Once a link has been attached to a connection, it cannot be attached to any other connection until an RDR_DETACH_REQ is processed on the original connection.

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

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

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

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

Chapter 4: Control PrimitivesRDR_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;There is no data part.

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.

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

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

Message FormatThe control part of this message is defined by the following structure:

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 35 for a description of each parameter.

The data part of the message contains protocol-specific configuration parameters. Each data part is described below:

CD-2 (FPS 117), Marconi 10-Bit, Modified Eurocontrol, General 18-Bit and NEC Radar Extractor Data PartThe 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: 31

Chapter 4: Control Primitivestypedef 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 37 for a description of each parameter.

ASTERIX Data PartFor 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;bit32 as_timeout_baud;bit32 as_fwd_time;

} as_bind_req_t;See as_bind_req_t Structure Parameters on page 40 for a description of each parameter.32

RDR_BIND_REQThompson-CSF, Thompson-TVT2 and Toshiba Data PartFor 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 42 for a description of each parameter.

TPS-43 and TPS-75 Data PartFor TPS-43 and TPS-75, the data part is defined as follows: 33

Chapter 4: Control Primitivestypedef 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 45 for a description of each parameter.

Raduga-2 Data PartFor Raduga-2, the data part is defined as follows:34

RDR_BIND_REQtypedef 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 47 for a description of each parameter.

Parameters

rdr_bind_req_t Structure ParametersThe 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

thompcsf Thompson-TVT2

toshiba Toshiba

tps43 TPS-43 35

Chapter 4: Control Primitiveseuro 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) 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) 36

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

cd_bind_req_t Structure ParametersThe 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.

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

Chapter 4: Control Primitivescd_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.

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

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

1 Insert idle words between messages to be transmitted. 39

Chapter 4: Control Primitivescd_purge_committed_data specifies whether the transmit BDs will be immediately purged of data when CTS/DCD go down. This parameter should be used in conjunction with cd_data_acks and cd_noclock_to to ensure that stale data is not left on the controller when CTS/DCD go back up. The preferred data purging mechanism is to use cd_noclock_to solely. This feature applies to xSTRa based platforms only.

cd_encoding specifies the type of encoding for the link (NexusWare platforms only), which is defined by the following structure:

typedef enum _wanStrC_serRxTxEncode_t{

WANSTRC_SER_RXTX_ENC_NRZ,WANSTRC_SER_RXTX_ENC_NRZ_INV,WANSTRC_SER_RXTX_ENC_NRZI_MARK,WANSTRC_SER_RXTX_ENC_NRZI_SPACE,WANSTRC_SER_RXTX_ENC_FM0,WANSTRC_SER_RXTX_ENC_FM1,WANSTRC_SER_RXTX_ENC_MANCHESTER,WNASTRC_SER_RXTX_ENC_DIFF_MANCHESTER

} wanStrC_serRxTxEncode_t;cd_idle_buf_to This parameter determines the amount of time (in tenths of a second)

allowed for transmission of an non 8-bit idle buffer when transmit data acknowledgements are enabled.

This parameter applies to NexusWare based platforms only.

as_bind_req_t Structure ParametersThe 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)

3 FM1 (QUICC platforms only)40

RDR_BIND_REQ4 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) Includes the requested message to transmit in the acknowledgement information. This option only applies to the NexusWare base Protocol controllers. 41

Chapter 4: Control PrimitivesSee AS_DATA_REQ on page 82 for further information on Data Acknowledgements.

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

as_timeout_baud specifies the line speed in bits/second. For example, if the line speed is 2400 bps, as_timeout_baud should be set to 2400. This value is used to calculate the time stamp for received messages.

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

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

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

A very small block size decreases the efficiency of the serial device driver, while a large block size increases the latency of received messages. (The time stamp on each message is always accurate, regardless of the configured block size.)

tc_contype specifies RDR_READONLY for normal receive-only operation, RDR_WRITEONLY to transmit data, or RDR_READWRITE which allows reading and writing on the same link (QUICC platforms only).

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:

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_NO_SIGS, changes in modem signals are ignored by the driver. 43

Chapter 4: Control PrimitivesRDR_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 BDs will be immediately purged of data when CTS/DCD go down. This parameter should be used in conjunction with tc_data_acks and tc_noclock_to to ensure that stale data is not left on the controller when CTS/DCD go back up. The preferred data purging mechanism is to use tc_noclock_to solely. This feature applies to xSTRa based platforms only.

tc_encoding specifies the type of encoding for the link (NexusWare platforms only), which is defined by the following structure:



} wanStrC_serRxTxEncode_t;tc_idle_buf_to this parameter determines the amount of time (in tenths of a second)


This parameter applies to NexusWare based platforms only.44

RDR_BIND_REQtp_bind_req_t Structure ParametersThe 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.

tp_dma_blocksize determines the number of 8-bit bytes to be received before the data is processed (assembled into messages and forwarded to the application). Blocks of the specified size are received by the serial device driver and passed to a radar protocol module for processing.

A very small block size decreases the efficiency of the serial device driver, while a large block size increases the latency of received messages. (The time stamp on each message is always accurate, regardless of the configured block size.) 45

Chapter 4: Control Primitivestp_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:

RDR_NO_SIGS, changes in modem signals are ignored by the driver.

RDR_SIGS, the driver will notify upstream modules when there is a change in modem input signals via a RDR_ERROR_IND with rdr_errno equal to either RDR_LINKUP or RDR_LINKDOWN.

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


V. 11 WANSTRPROT_PHYIF_V11 or 0

RS530A WANSTRPROT _PHYIF_RS530A or 1


X.21 WANSTRPROT _PHYIF_X21 or 3

V.35 WANSTRPROT _PHYIF_V35 or 4



HIZ WANSTRPROT _PHYIF_HIZ or 7

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

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

tp_encoding Specifies the type of encoding for the link (NexusWare platforms only), which is defined by the following structure:



} wanStrC_serRxTxEncode_t;tp_idle_buf_to This parameter determines the amount of time (in tenths of a second)


This parameter applies to NexusWare based platforms only.

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

raduga2_bind_req_t Structure ParametersThe 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.

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 trans

Documents

Radar Receiver Manual