Radar Receiver Manual

Radar Receiver User Guide
Radar Receiver
User's Guide
Performance Technologies 205 Indigo Creek Drive Rochester, NY 14626 585.256.0200 support@pt.com
www.pt.com
2007 Performance Technologies, Inc. All Rights Reserved.
Document Revision History Part Number

106p0900.10 106p0900.20 106p0900.30 106p0900.31 106p0900.32 106p0900.33 106p0900.40 106p0900.41 106p0900.50 106p0900.51 106p0900.52 106p0900.53
Date
05/28/98 09/30/98 09/07/99 01/10/01 03/07/01 09/09/02 01/29/03 07/09/03 10/17/03 02/09/04 03/26/04 07/29/04
Explanation of changes
Initial Release New Feature Added TPS-75 Protocol Update to Idle non 8-bit pattern and Modem Status Notification Document new functionality in RDR_ERROR_IND Reformatting All Added TPS43C protocol information, Chapter 4, Control Primitives Multiple Updates Added tps43_D Protocol information Added cd_bind_req_t structure modifications and definitions. Modified data format for CD-2, Chapter 4 Added/changed as_bind_req_t, tc_bind_req_t, and cd_bind_req_t structure modifications and definitions, Chapter 4 tc_bind_req_t, and cd_bind_req_t structure modifications and definitions, cd_encoding definitions and tc_encoding definitions Added Raduga-2 Protocol Added Programmable Physical Interface for CPC358 information to Sample Test Programs. Chapter 5, Sample Test Programs Modified cd_purge_committed_data definition, Chapter 4
106p0900.54 106p0900.55 106p0900.56 106p0900.60 106p0900.61
09/21/04 01/31/05 06/08/06 02/16/07 08/03/07
Add support to specify using external clock source for timestamps. Add support to setup optional transmit data acknowledgement timestamps and data. Corrected RDR_CLEAR_TICK, RDR_DATA_ACK, RDR_ERROR_ACK, WANSTRPROT_TS_CLOCK_INACCURATE, cd_bind_req_t structure. Reformatted book.
106p0900.62
10/26/07
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.
Disclaimer This 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. Trademarks This 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 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. 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 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 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.
Contents
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
Chapter 3: Radar Daemon Process
21
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Configuration File Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Running the Radar Daemon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Chapter 4: Control Primitives
25
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5
Contents
RDR 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 Reasons for Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 RDR_BIND_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 New State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 Reasons for Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 RDR_BIND_ACK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 New State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 RDR_UNBIND_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 New State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Reasons for Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6
Contents
RDR_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 Reasons for Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 CD_STATISTICS_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 New State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 Reasons for Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
7
Contents
CD_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 Reasons for Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
8
Contents
TP_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 Reasons for Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 AS_DATA_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 New State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 Reasons for Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 TC_DATA_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
9
Contents
New State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Reasons for Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 TP_DATA_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 New State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 Reasons for Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 RADUGA2_DATA_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 New State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 Reasons for Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 RDR_DATA_IND . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
10
Contents
Run the Transmit and Receive Test Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 Run the Full Duplex Radar Test Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Index
117
11
Contents
12
Chapter
1
About This Guide
Overview
This manual covers the following information regarding the Radar Receiver software package: Chapter 2, Introduction to Radar Receiver on page 17 describes the programming interface to the Radar Receiver (RDR) software package. This interface is derived from the Data Link Provider Interface Specification published by UNIX International. Chapter 3, Radar Daemon Process on page 21. The RDR software includes a multiplexing module that allows one application connection to receive data from more than one serial line. The serial lines must be configured and initialized before applications can open connections and begin sending or receiving data. A background system-level program, or daemon is supplied to perform this function. Chapter 4, Control Primitives on page 25 describes the format of each of the supported DLPI primitives for the Radar Receiver protocols. These primitives are used by the application to convey control requests such as the bind, and are used by RDR to provide the application with event indications and responses to control requests. In addition, the primitives are used to receive radar messages. Chapter 5, Sample Test Programs on page 107 contains examples of the interface to RDR. Three test programs are included in source form with the release and are located in the Radar Client directory.
13
Text Conventions
This guide uses the following conventions: Convention
Monospace font
Bold font
What it is Used For

Monospace font is used to represent sample code. Bold font is used to represent: pathnames filenames UNIX commands user input
Italic font
Italic font is used to represent: notes that supply useful advice general information referenced documents
$ARCH
Indicates the processor architecture of the target; currently this is ppc, mips, arm and i386. Angle brackets are used to represent variables such as file names, passwords, and so on. Regular font is used for the ENTER and TAB keys and the SPACEBAR on your keyboard. The caution icon indicates information that may prevent loss of data.
<> Regular font
The warning icon indicates information that may prevent physical harm to the user or the hardware.
Customer Support and Services

Performance 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 support@pt.com. 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.
14
Product Warranty
3. 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). Performance Technologies Support Contact Numbers
Embedded Systems
Email FAX Phone
Embedded Software
support@pt.com
(858) 627-1710 (585) 256-0791 (858) 627-1700 (M-F, 8 to 5 Pacific) (585) 256-0248 (M-F, 8 to 5 Eastern)
support@pt.com
(585) 256-0791 (805) 541-5088 (585) 256-0248 (M-F, 8 to 5 Eastern) (805) 783-6004 (M-F, 8 to 5 Pacific)
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 Warranty
Performance 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.
15
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 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
Chapter
2
Introduction to Radar Receiver
Overview
This 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. 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, Performance Technologies supports a connectionless mode of service.
Radar Data Formats

The Radar Receiver supports the following radar data formats:
CD-2 (also known as FPS 117) Marconi 10-Bit ASTERIX (also known as Alenia, Selenia, Ericsson, RDIF, RAMP) Thompson-CSF (also known as TPR1000) Thompson-TVT2 Toshiba TPS-43 (can be configured as Common Format) Modified Eurocontrol
17
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 Interface

Applications 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 Configuration
The 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 Services
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.
Overview of DLPI Services

Before the Radar Receiver primitives can be used, the application must open a connection to RDR using the MPSopen API call, specifying protocol name rdrmux. A radar swap module is provided with for controllers and servers which interface with a host system which has little endian architecture. It should be pushed onto the stream (using the MPSioctl call) after the open to the radar mux has occurred. Next, the application must bind one or more Data Link Service Access Points (DLSAPs) to the connection. A DLSAP specifies a serial link over which data on the connection is to be transferred. The bind request includes configuration parameters for the data link connection. On receipt of this request, RDR initializes the serial link and enables the receiver. At this point, the application may begin receiving data messages. When data transfer operations are complete, the application should send an unbind request to deactivate the connection and free the associated DLSAP. When interactions between the application and RDR are complete, the application should close the connection using MPSclose. Figure 2-1, Radar Receiver System Configuration, on page 20 shows the Radar Receiver System Configuration.
19
Figure 2-1: Radar Receiver System Configuration
20
Chapter
3
Radar Daemon Process
Overview
The RDR software includes a multiplexing module that allows one application connection to receive data from more than one serial line. The serial lines must be configured and initialized before applications can open connections and begin sending or receiving data. A background system-level program, or daemon is supplied to perform this function. Source code for the daemon process, rdrd.c, is included with the RDR release in the Radar Daemon directory. The INSTALL procedure builds the daemon and copies it to /etc (if in the UNIX environment). The daemon reads configuration parameters for each physical link from a text file. A sample configuration file, rdrconfig, is also included in the source code directory and copied to /etc (if in the UNIX environment) by the INSTALL script. The sample file contains default parameters to initialize eight serial links for an assortment of radar protocols. Also provided are configurations which set up the controller for one specific radar protocol. The names of the files reflect the protocol name. You should modify one of these configuration files according to your specific site requirements. The format of the configuration file immediately follows. Running the Radar Daemon on page 23 explains how to run the daemon process. Topics included in this chapter include:
Configuration File Format, on page 22 Running the Radar Daemon, on page 23
21
Configuration File Format

The daemon process uses the information in the configuration file to configure one or more serial lines on a controller. The parameters specified in the file determine the corresponding parameters of the RDR_ATTACH_REQ primitive, which the daemon sends to the controller during the initialization process. For further information regarding this request and a more detailed description of each parameter, see RDR_ATTACH_REQ, on page 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 protocol
specifies the serial line, numbered from zero. (The maximum valid link number depends on the hardware platform.) determines the radar data format to be used. Valid protocol names are shown in Table 3-1: Valid Protocols:
Table 3-1: Valid Protocols Radar Data Format

CD-2 FPS 117 Marconi 10-Bit ASTERIX Thompson-CSF Thompson-TVT2 Toshiba TPS-43 Modified Eurocontrol General 18-Bit NEC Radar Extractor TPS-75 Raduga-2
Protocol
cd2 cd2 marconi10 asterix thompcsf thompcsf toshiba tps43 euro gen18 nec tps75 raduga-2
A sample configuration file for four serial links is shown below.
22
Running the Radar Daemon
link protocol link protocol link protocol link protocol
0 marconi10 1 asterix 2 asterix 3 cd2
Running the Radar Daemon

The Radar daemon must be executed after the server or communication controller has been downloaded and before any application process attempts to establish a connection to the Radar Receiver. The daemon should be executed in the background, and must not be terminated as long as any applications require access to the Radar Receiver. To run the daemon, use the following command:
rdrd [ -f config_file ] [ -v ] [ -s server ] [ -c controller ] &
-f config_file
This option can be used to specify the pathname of the configuration file. If this option is not included, the pathname defaults to /etc/ rdrconfig for UNIX, or rdrconfig in the current directory for Windows NT. This option causes the daemon to print status information as it configures and initializes the Radar Receiver. This option identifies the target server. For a LAN-based server, this is the logical host name as specified in the client's hosts database. For a controller installed in a backplane, server is the pathname of the driver's cloneable special file. If this option is not specified, the server name defaults to /dev/ucsclone for UNIX, or \\.\PTIXpqcc for Windows NT. This parameter specifies the controller number. If not specified, controller defaults to 0.
-v -s server
-c controller
23
24
Chapter
4
Control Primitives
Overview
This section describes the format of each of the supported DLPI primitives for the Radar Receiver protocols. These primitives are used by the application to convey control requests such as the bind, and are used by RDR to provide the application with event indications and responses to control requests. In addition, the primitives are used to receive radar messages. Topics included in this chapter include:
RDR Primitives on page 26 RDR_ATTACH_REQ on page 28 RDR_DETACH_REQ on page 30 RDR_BIND_REQ on page 31 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 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 68
25
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 Primitives
All RDR primitives are sent and received using MPSputmsg and MPSgetmsg, respectively. Most contain only a control part. The following primitives also include a data part:
RDR_BIND_REQ CD_STATISTICS_ACK AS_STATISTICS_ACK TC_STATISTICS_ACK TP_STATISTICS_ACK RDR_DATA_IND
Most primitives are common to all supported radar data formats. The exceptions are as follows:
RDR_BIND_REQ has a common control part, but the data part has a different format depending on the radar type. Different primitives are used to transmit radar data on a serial link, see Table 4-1: RDR Primitives Used to Transmit Radar Data on a Serial Link:
Table 4-1: RDR Primitives Used to Transmit Radar Data on a Serial Link Radar Data Format
CD-2 (FPS 117) Marconi 10-Bit ASTERIX Thompson-CSF Thompson-TVT2 Toshiba TPS-43 Modified Eurocontrol General 18-Bit NEC Radar Extractor
RDR Primitive Used

CD_DATA_REQ CD_DATA_REQ AS_DATA_REQ TC_DATA_REQ TC_DATA_REQ TC_DATA_REQ TP_DATA_REQ CD_DATA_REQ CD_DATA_REQ CD_DATA_REQ
26
RDR Primitives
Table 4-1: RDR Primitives Used to Transmit Radar Data on a Serial Link (Continued)
TPS-75 Raduga-2 TP_DATA_REQ RADUGA2_DATA_REQ
RDR_DATA_IND provides the application with all types of received radar messages. The format of each radar message within the data part depends on the radar data format configured for the serial link on which the message was received. Different primitives are used to request and provide statistical information about a serial link, see Table 4-2: RDR Primitives Used to Request Statistics About a Serial Link:
Table 4-2: RDR Primitives Used to Request Statistics About a Serial Link Radar Data Format
CD-2 (FPS 117) Marconi 10-Bit ASTERIX Thompson-CSF Thompson-TVT2 Toshiba TPS-43 Modified Eurocontrol General 18-Bit NEC Radar Extractor TPS-75 Raduga-2
Primitive Used to Request Statistics

CD_STATISTICS_REQ CD_STATISTICS_REQ AS_STATISTICS_REQ TC_STATISTICS_REQ TC_STATISTICS_REQ TC_STATISTICS_REQ TP_STATISTICS_REQ CD_STATISTICS_REQ CD_STATISTICS_REQ CD_STATISTICS_REQ TP_STATISTICS_REQ RADUGA2_STATISTICS_REQ
Primitive That Provides Statistics

CD_STATISTICS_ACK CD_STATISTICS_ACK AS_STATISTICS_ACK TC_STATISTICS_ACK TC_STATISTICS_ACK TC_STATISTICS_ACK TP_STATISTICS_ACK CD_STATISTICS_ACK CD_STATISTICS_ACK CD_STATISTICS_ACK TP_STATISTICS_ACK RADUGA2_STATISTICS_ACK
Each primitive description in this section includes a structure definition for the control part of the message. The structure definitions vary, but the first field always specifies the primitive type. The primitive type determines the format of the remainder of the message. The message types and structures referenced in this section are defined in the files dlpirdr.h, dlpiast.h, dlpicd2.h, dlpitcsf.h, dlpitps43.h, and dlpiraduga2.h. These files use typedefs defined in the include file xstypes.h located in the include directory.
27
RDR_ATTACH_REQ
To configure the Radar Receiver system on a communication controller, the daemon program (see Running the Radar Daemon on page 23) must:
Open a connection to the radar protocol module for each physical link to be configured. Push the radar swap module if the system requires it (little endian architecture). Open a single connection to the radar mux module. For each radar protocol connection, use the APIs MPSioctl call to send a request of type X_LINK to the radar mux, linking the protocol connection underneath the radar mux. Send an attach request to the radar mux for each radar protocol connection (one for each physical link).
The RDR_ATTACH_REQ message is sent by the daemon to request that RDR attach a physical link to the connection. This request informs the radar mux of the protocol type (radar data format) assigned to each of its lower-level streams. Once a link has been attached to a connection, it cannot be attached to any other connection until an RDR_DETACH_REQ is processed on the original connection.
Message Format
The control part of this message is defined by the following structure: typedef struct { bit32 rdr_primitive; bit32 rdr_link; bit32 rdr_l_index; char rdr_protocol[24]; } rdr_attach_req_t; There is no data part.
Parameters
rdr_primitive rdr_link conveys RDR_ATTACH_REQ. identifies the serial link that will be associated with the connection. Links are numbered beginning at zero. (The maximum link number depends on the hardware platform.) must specify the link ID that was returned from the MPSioctl X_LINK request. is an ASCII string identifying the radar data format associated with the connection, as follows: cd2 marconi10 asterix thompcsf
28
rdr_l_index rdr_protocol
CD-2 or FPS 117 Marconi 10-Bit ASTERIX Thompson-CSF
RDR_ATTACH_REQ
thompcsf toshiba tps43 euro gen18 nec tps75 raduga2
Thompson-TVT2 Toshiba TPS-43 Modified Eurocontrol General 18-Bit NEC Radar Extractor TPS-75 Raduga-2
State
This message is valid in state RDR_NOTATTACHED.
New State
The resulting state is RDR_ATTACH_PENDING.
Response
When RDR successfully processes the attach request, it sends RDR_OK_ACK to the application and the resulting state is RDR_UNBOUND. If the request is in error, RDR returns RDR_ERROR_ACK instead and the state reverts to RDR_NOTATTACHED. In either case, the rdr_modifier field of the returned primitive identifies the serial link (rdr_link).
Reasons for Failure

RDR_ATTACHED RDR_NOSUCHPROTOCOL RDR_NOTAUTHOR Requested physical link is already attached. rdr_protocol string is invalid. Link ID specified in rdr_l_index is invalid.
29
RDR_DETACH_REQ
This message is sent by the background daemon process to request RDR to detach the physical link that was previously attached to the connection with an RDR_ATTACH_REQ. This message is normally sent by the daemon only when it is shutting down the Radar Receiver system before exiting. Any applications with an open connection to RDR on the specified serial link will receive disconnect indications.
Message Format
The control part of the message is defined by the following structure: typedef struct { bit32 rdr_primitive; bit32 rdr_link; } rdr_primitive; There is no data part.
Parameters
rdr_primitive rdr_link conveys RDR_DETACH_REQ. specifies the serial link to be detached.
State
This message is valid in state RDR_UNBOUND or RDR_DATAXFER.
New State
The resulting state is RDR_DETACH_PENDING.
Response
In response, RDR sends RDR_OK_ACK to the application and the new state is RDR_NOTATTACHED. If the request is in error, RDR_ERROR_ACK is returned instead and the state reverts to the state from which the RDR_DETACH_REQ was issued.
Reasons for Failure

RDR_INVALIDPORT The link number specified in rdr_link is invalid.
30
RDR_BIND_REQ
RDR_BIND_REQ
This message is sent by the application to request that RDR bind a DLSAP to the connection. This request configures and enables the associated serial link. The radar mux allows multiple DLSAPs to be bound to a single connection. However, once a DLSAP has been bound to a connection, it cannot be bound to any other connection until a RDR_UNBIND_REQ is processed on the original connection.
Message Format
The control part of this message is defined by the following structure: typedef struct { bit32 bit32 char bit32 bit32 wanStrProt_txDataAcks_t wanStrProt_options1_t } rdr_bind_req_t;
rdr_primitive; rdr_link; rdr_protocol[24]; rdr_max_messages; rdr_message_timeout; rdr_data_acks; rdr_options1;
See rdr_bind_req_t Structure Parameters on page 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 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:
31
typedef struct { bit32 bit32 bit32 bit32 bit32 bit32 bit32 bit32 bit32 bit32 bit32 bit32 bit32 bit32 bit32 bit32 wanStrProt_phyIf_t bit32 bit32 bit32 wanStrC_serRxTxEncode_t bit32 } cd_bind_req_t;
cd_primitive; cd_link; cd_baud; cd_timeout_baud; cd_packmesg; cd_maxmesg_size; cd_maxmesg_cnt; cd_fwd_time; cd_dma_blocksize; cd_contype; cd_sync; cd_invert; cd_do_idle; cd_idle_pattern; cd_modem_in; cd_sigtimeout; phyIf; cd_xmt_unpackmesg; cd_xmt_idles; cd_purge_committed_data; cd_encoding; cd_idle_buf_to;
See cd_bind_req_t Structure Parameters on page 37 for a description of each parameter.
ASTERIX Data Part

For ASTERIX, the data part is defined by the following structure: typedef struct { bit32 bit32 bit32 bit32 bit32 bit32 dlpiAst_phyIf_t wanStrProt_txDataAcks_t bit32 bit32 bit32 } as_bind_req_t;
as_link; as_framesize; as_baud; as_encoding; as_mode; as_modem; phyIf; as_data_acks; as_purge_committed_data; as_timeout_baud; as_fwd_time;
See as_bind_req_t Structure Parameters on page 40 for a description of each parameter.
32
RDR_BIND_REQ
Thompson-CSF, Thompson-TVT2 and Toshiba Data Part

For Thompson-CSF, Thompson-TVT2 and Toshiba, the data part is defined as follows: typedef struct { bit32 bit32 bit32 bit32 bit32 bit32 bit32 bit32 bit32 bit32 bit32 bit32 bit32 bit32 bit32 wanStrProt_phyIf_t bit32 wanStrC_serRxTxEncode_t bit32 } tc_bind_req_t;
tc_primitive; tc_link; tc_baud; tc_timeout_baud; tc_maxmesg_size; tc_maxmesg_cnt; tc_fwd_time; tc_dma_blocksize; tc_contype; tc_sync; tc_check_crc; tc_time_delay; tc_variant; tc_modem_in; tc_sigtimeout; phyIf; tc_purge_committed_data; tc_encoding; tc_idle_buf_to;
See tc_bind_req_t Structure Parameters on page 42 for a description of each parameter.
TPS-43 and TPS-75 Data Part

For TPS-43 and TPS-75, the data part is defined as follows:
33
typedef struct { bit32 bit32 bit32 bit32 bit32 bit32 bit32 bit32 bit32 bit32 bit32 bit32 bit32 bit32 wanStrProt_phyIf_t bit32 bit32 wanStrC_serRxTxEncode_t bit32 bit32 } tp_bind_req_t;
tp_primitive; tp_link; tp_baud; tp_timeout_baud; tp_maxmesg_size; tp_maxmesg_cnt; tp_fwd_time; tp_dma_blocksize; tp_contype; tp_sync; tp_idle; tp_modem_in; tp_sigtimeout; tp_relaxed_data_gathering; phyIf; tp_error_info; tp_purge_committed_data; tp_encoding; tp_idle_buf_to; tp_enhanced
See tp_bind_req_t Structure Parameters on page 45 for a description of each parameter.
Raduga-2 Data Part

For Raduga-2, the data part is defined as follows:
34
RDR_BIND_REQ
typedef struct { bit32 bit32 bit32 bit32 bit32 bit32 bit32 bit32 bit32 bit32 bit32 bit32 bit32 bit32 bit32 bit32 wanStrProt_phyIf_t bit32 wanStrC_serRxTxEncode_t bit32 } raduga2_bind_req_t;
raduga2_primitive; raduga2_link; raduga2_baud; raduga2_timeout_baud; raduga2_maxmesg_size; raduga2_maxmesg_cnt; raduga2_fwd_time; raduga2_dma_blocksize; raduga2_contype; raduga2_sync; raduga2_check_crc; raduga2_check_parity; raduga2_modem_in; raduga2_sigtimeout; raduga2_do_idle; raduga2_idle_pattern; phyIf; raduga2_purge_committed_data; raduga2_encoding; cd_idle_buf_to;
See raduga2_bind_req_t Structure Parameters on page 47 for a description of each parameter.
Parameters
rdr_bind_req_t Structure Parameters
The rdr_bind_req_t structure defines the control part of the message for all radar data formats: rdr_primitive rdr_link conveys RDR_BIND_REQ. identifies the DLSAP that will be bound to the connection. A DLSAP is equivalent to a link number, where links are numbered beginning at zero. (The maximum link number depends on the hardware platform.) is an ASCII string identifying the radar data format configured for the associated serial link, as follows: cd2 marconi10 asterix thompcsf thompcsf toshiba tps43 CD-2 or FPS 117 Marconi 10-Bit ASTERIX Thompson-CSF Thompson-TVT2 Toshiba TPS-43
35
rdr_protocol
euro gen18 nec tps75 raduga2 rdr_max_messages
Modified Eurocontrol General 18-Bit NEC Radar Extractor TPS-75 Raduga-2
configures the maximum number of received radar messages, from all DLSAPs bound to the connection, that will be accumulated by the radar mux before they are forwarded to the application in the data portion of an RDR_DATA_IND primitive. If more than one DLSAP is bound to a single connection, this parameter should have the same value in each RDR_BIND_REQ.
rdr_message_timeout specifies the length of time, in increments of one hundred milliseconds, RDR waits before sending an RDR_DATA_IND primitive to the application when rdr_max_messages has not been reached. rdr_data_acks specifies whether or not acknowledgments are sent, and what is included in the acknowledgement, in response to DATA_REQ primitives. This option only applies to links that are configured in writeonly and readwrite mode. This parameter is an enumeration and is treated as a bit field where more than one feature can be or'd together. The bit definitions are:
WANSTRPROT_TX_DATA_ACKS_DISABLE (0x0000000)
Disables acknowledgements.
WANSTRPROT_TX_DATA_ACKS_ENABLE (0x00000001)
Enable acknowledgments.
WANSTRPROT_TX_DATA_ACKS_WITH_TIMESTAMPS (0x00000002)
Includes valid timestamp in the acknowledgement information. This option only applies to the NexusWare base Protocol controllers.
WANSTRPROT_TX_DATA_ACKS_WITH_DATA (0x00000004)
Includes the requested message to transmit in the acknowledgement information. This option only applies to the NexusWare base Protocol controllers. See the applicable Radar Protocol DATA_REQ for further information on Data Acknowledgements. rdr_options1 This parameter is an enumeration and is treated as a bit field where more than one feature can be or'd together. The bit definitions are:
WANSTRPROT_OPT1_END_OF_MSG_TIMESTAMPS (0x00000001)
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_REQ
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.
cd_bind_req_t Structure Parameters

The cd_bind_req_t structure defines the data part of the message for CD-2 (FPS 117), Marconi 10-Bit, Modified Eurocontrol, General 18-Bit and NEC Radar Extractor: cd_primitive cd_link not used. identifies the DLSAP that will be bound to the connection. This parameter must have the same value as the rdr_link field in the control part of the message. specifies the line speed for the connection. A value of -1 for this parameter configures the link for external clocking, meaning that the transmit clock must be supplied by an external device (such as a modem). The receive clock signal is configured as an input (supplied by the transmitting device or other external device). For a normal receive-only connection, cd_baud should always be set to -1. cd_timeout_baud specifies the line speed in bits/second. For example, if the line speed is 2400 bps, cd_timeout_baud should be set to 2400. This value is used to calculate the time stamp for received messages and is not used for a transmit-only connection. determines how RDR will format radar messages within the data portion of RDR_DATA_IND primitives, as follows: 0 Data is unpacked. For CD-2 and Marconi 10-Bit, this means that each 16-bit word of the message contains one 10- or 13-bit word of radar data, with the unused upper bits set to zero. For Modified Eurocontrol and General 18-Bit, unpacked format means that each 32-bit long word of the message contains one 18-bit word of radar data, with the unused upper 14 bits set to zero. Data is packed, meaning that bits of consecutive words of radar data are contiguous within the 16-bit words of the message.
cd_baud
cd_packmesg
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
cd_maxmesg_size
specifies the number of bytes required to store the maximum-length radar message in the selected data format. For example, if the maximum radar message size is 7 13-bit words, cd_maxmesg_size should be set to 14 if cd_packmesg is 0; or 12 if cd_packmesg is 1. RDR uses this value to identify errors in received data and to format messages within the data portion of RDR_DATA_IND primitives. defines the maximum number of data messages that will be accumulated by the radar protocol module before they are forwarded to the radar mux. specifies the length of time, in increments of one hundred milliseconds, the radar protocol module waits before sending a block of received messages to the radar mux when cd_maxmesg_cnt has not been reached. determines the number of 8-bit bytes to be received before the data is processed (assembled into messages and forwarded to the application). Blocks of the specified size are received by the serial device driver and passed to a radar protocol module for processing. A very small block size decreases the efficiency of the serial device driver, while a large block size increases the latency of received messages. (The time stamp on each message is always accurate, regardless of the configured block size.)
cd_maxmesg_cnt
cd_fwd_time
cd_dma_blocksize
cd_contype
specifies RDR_READONLY for normal receive-only operation, RDR_WRITEONLY to transmit data, or RDR_READWRITE which allows reading and writing on the same link (QUICC platforms only). for all protocols except GENERAL 18-Bit, this parameter is reserved and should be set to zero. For General 18-Bit, this parameter should be set to the desired 18-bit sync pattern. configures the link for data bit inversion, as follows: 0 1 No inversion Invert data bits
cd_sync
cd_invert
If data bit inversion is selected, a ones complement operation is performed on all data after reception or before transmission. cd_do_idle specifies that the Radar Protocol should idle out of the non 8-bit idle pattern defined in the cd_idle_pattern. If set, the protocol will construct the minimum sized buffer that will contain the non 8-bit idle pattern without padding to the end of a byte. This is not applicable for links set to READONLY. user specified non 8-bit idle sequence (in lieu of the standard 8-bit idle character) for CD-2, Marconi 10-bit, Modified Eurocontrol, or General 18-bit protocols, when no radar data is being transmitted on the serial link. specifies how the SBSI driver should handle changes in modem input signals during link operation:
cd_idle_pattern
cd_modem_in
38
RDR_BIND_REQ
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. The phyIf field configures the physical interface of a CPC358. It is ignored by all other products. The supported interfaces and their respective values are: V. 11 RS530A RS530 X.21 V.35 RS449 RS232 HIZ WANSTRPROT_PHYIF_V11 or 0 WANSTRPROT _PHYIF_RS530A or 1 WANSTRPROT _PHYIF_RS530 or 2 WANSTRPROT _PHYIF_X21 or 3 WANSTRPROT _PHYIF_V35 or 4 WANSTRPROT _PHYIF_RS449 or 5 WANSTRPROT _PHYIF_RS232 or 6 WANSTRPROT _PHYIF_HIZ or 7
phyIf
cd_xmt_unpackmesg for all protocols except NEC Radar, determines how RDR will interpret the format of radar messages within the data portion of CD_DATA_REQ primitives, as follows: 0 Data is packed, meaning that bits of consecutive words of radar data are contiguous within the 16-bit words of the message. Data is unpacked. For CD-2 this means that each 16-bit word of the message contains a 13-bit word of radar data, with the upper three bits unused.
cd_xmt_idles
for all protocols except NEC Radar, determines if RDR will insert idle words between messages to be transmitted. If idles are inserted, the CD-2 protocol will format the total number of data bytes to end on a 13bit boundary. 0 Do not insert idle words between messages to be transmitted. Assume the data portion of the CD_DATA_REQ primitive includes them. Insert idle words between messages to be transmitted.
39
cd_purge_committed_data specifies whether the transmit BDs will be immediately purged of data when CTS/DCD go down. This parameter should be used in conjunction with cd_data_acks and cd_noclock_to to ensure that stale data is not left on the controller when CTS/DCD go back up. The preferred data purging mechanism is to use cd_noclock_to solely. This feature applies to xSTRa based platforms only. cd_encoding specifies the type of encoding for the link (NexusWare platforms only), which is defined by the following structure:
typedef enum _wanStrC_serRxTxEncode_t { WANSTRC_SER_RXTX_ENC_NRZ, WANSTRC_SER_RXTX_ENC_NRZ_INV, WANSTRC_SER_RXTX_ENC_NRZI_MARK, WANSTRC_SER_RXTX_ENC_NRZI_SPACE, WANSTRC_SER_RXTX_ENC_FM0, WANSTRC_SER_RXTX_ENC_FM1, WANSTRC_SER_RXTX_ENC_MANCHESTER, WNASTRC_SER_RXTX_ENC_DIFF_MANCHESTER } wanStrC_serRxTxEncode_t;
cd_idle_buf_to
This parameter determines the amount of time (in tenths of a second) allowed for transmission of an non 8-bit idle buffer when transmit data acknowledgements are enabled. This parameter applies to NexusWare based platforms only.
as_bind_req_t Structure Parameters

The as_bind_req_t structure defines the data part of the message for ASTERIX: as_link identifies the DLSAP that will be bound to the connection. This parameter must have the same value as the rdr_link field in the control part of the message. configures the maximum size of an ASTERIX message. specifies the line speed for the connection. A value of -1 for this parameter configures the link for external clocking, meaning that the transmit clock must be supplied by an external device (such as a modem). The receive clock signal is configured as an input (supplied by the transmitting device or other external device). For a normal receive-only connection, cd_baud should always be set to -1. as_encoding data encoding for the link as follows: 0 1 2 3
40
as_framesize as_baud
NRZ NRZI FM0 for RAMP Radar (QUICC platform only) FM1 (QUICC platforms only)
RDR_BIND_REQ
4 5 as_mode as_modem
Manchester (QUICC platforms only) Differential Manchester (QUICC platforms only)
must be set to 0. determines whether the serial device driver requires the clear to send (CTS) and data carrier detect (DCD) modem signals, as follows: 1 0 Link initialization fails if the device driver does not detect CTS and DCD within 90 seconds. Link initialization succeeds regardless of whether CTS and DCD are present.
The device driver always turns on the request to send (RTS) and data terminal ready (DTR) signals when it initializes the serial link. phyIf The phyIf field configures the physical interface of a CPC358. It is ignored by all other products. The supported interfaces and their respective values are: V. 11 RS530A RS530 X.21 V.35 RS449 RS232 HIZ as_data_acks DLPIAST_PHYIF_V11 or 0 DLPIAST_PHYIF_RS530A or 1 DLPIAST_PHYIF_RS530 or 2 DLPIAST_PHYIF_X21 or 3 DLPIAST_PHYIF_V35 or 4 DLPIAST_PHYIF_RS449 or 5 DLPIAST_PHYIF_RS232 or 6 DLPIAST_PHYIF_HIZ or 7
specifies whether or not acknowledgments are sent, and what is included in the acknowledgement, in response to DATA_REQ primitives. This option only applies to links that are configured in writeonly and readwrite mode. This parameter is an enumeration and is treated as a bit field where more than one feature can be or'd together. The bit definitions are:
WANSTRPROT_TX_DATA_ACKS_DISABLE (0x0000000)
Disables acknowledgements.
WANSTRPROT_TX_DATA_ACKS_ENABLE (0x00000001)
Enable acknowledgments
WANSTRPROT_TX_DATA_ACKS_WITH_TIMESTAMPS (0x00000002)
Includes valid timestamp in the acknowledgement information. This option only applies to the NexusWare base Protocol controllers.
WANSTRPROT_TX_DATA_ACKS_WITH_DATA (0x00000004)
Includes the requested message to transmit in the acknowledgement information. This option only applies to the NexusWare base Protocol controllers.
41
See AS_DATA_REQ on page 82 for further information on Data Acknowledgements. as_purge_committed_data specifies whether the transmit BDs will be immediately purged of data when CTS/DCD go down. This parameter should be used in conjunction with as_data_acks and as_noclock_to to ensure that stale data is not left on the controller when CTS/DCD go back up. The preferred data purging mechanism is to use as_noclock_to solely. This feature applies to xSTRa based platforms only. as_timeout_baud specifies the line speed in bits/second. For example, if the line speed is 2400 bps, as_timeout_baud should be set to 2400. This value is used to calculate the time stamp for received messages. specifies the length of time, in increments of one hundred milliseconds, the radar protocol module waits before sending an empty message to the radar mux when no radar messages have been received.
as_fwd_time
tc_bind_req_t Structure Parameters

The tc_bind_req_t structure defines the data part of the message for Thompson-CSF, Thompson-TVT2 and Toshiba: tc_primitive tc_link not used. identifies the DLSAP that will be bound to the connection. This parameter must have the same value as the rdr_link field in the control part of the message. specifies the line speed for the connection. A value of -1 for this parameter configures the link for external clocking, meaning that the transmit clock must be supplied by an external device (such as a modem). The receive clock signal is configured as an input (supplied by the transmitting device or other external device). For a normal receive-only connection, cd_baud should always be set to -1. tc_timeout_baud specifies the line speed in bits/second. For example, if the line speed is 2400 bps, tc_timeout_baud should be set to 2400. This value is used to calculate the time stamp for received messages. In the Toshiba radar protocol, this value is also used in conjunction with the desired time delay value (tc_fwd_time) to calculate how much idle padding to append to a transmitted message. specifies the maximum length of a received Thompson-CSF, Thompson-TVT2 or a Toshiba radar message, in bytes. 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
tc_baud
tc_maxmesg_size
RDR_BIND_REQ
For a Toshiba radar message, the specified length must include the BSC control characters, CRC bytes and any expansion of the data for transparency. To determine the correct value for this parameter, double the expected maximum data size (for transparency) and add 9 (for the header, control characters and CRC). tc_maxmesg_cnt defines the maximum number of data messages that will be accumulated by the radar protocol module before they are forwarded to the radar mux. specifies the length of time, in increments of one hundred milliseconds, the radar protocol module waits before sending a block of received messages to the radar mux when tc_maxmesg_cnt has not been reached. determines the number of 8-bit bytes to be received before the data is processed (assembled into messages and forwarded to the application). Blocks of the specified size are received by the serial device driver and passed to a radar protocol module for processing. A very small block size decreases the efficiency of the serial device driver, while a large block size increases the latency of received messages. (The time stamp on each message is always accurate, regardless of the configured block size.) tc_contype specifies RDR_READONLY for normal receive-only operation, RDR_WRITEONLY to transmit data, or RDR_READWRITE which allows reading and writing on the same link (QUICC platforms only). specifies the hexadecimal value of the sync character; 0x32 for Thompson-CSF and Toshiba, and 0x16 for Thompson-TVT2. configures CRC checking for received messages as follows: 0 1 tc_time_delay Ignore CRC Discard messages with CRC errors
tc_fwd_time
tc_dma_blocksize
tc_sync tc_check_crc
This parameter has a special purpose for a transmit link configured for the Toshiba radar protocol. The time delay value in milliseconds is specified with this parameter. This will allow the client transmit program to specify a minimum time gap between successive messages. The radar protocol will calculate the number of idle characters (based on the baud rate and the time delay desired) to append to each message transmitted. specifies the type of Thompson radar format (not used by Toshiba) as follows: THOMP_A THOMP_B Thompson-CSF Thompson-TVT2
tc_variant
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
RDR_SIGS, the driver will notify upstream modules when there is a change in modem input signals via a RDR_EROR_IND with rdr_errno equal to either RDR_LINKUP or RDR_LINKDOWN. tc_sigtimeout specifies the amount of time (in10ms increments) to delay before processing a modem signal interrupt (normally referred to a debounce time). This parameter applies only if the tc_modem_in parameter is set to set to RDR_SIGS. The phyIf field configures the physical interface of a CPC358. It is ignored by all other products. The supported interfaces and their respective values are: V. 11 RS530A RS530 X.21 V.35 RS449 RS232 HIZ DLPIAST_PHYIF_V11 or 0 DLPIAST_PHYIF_RS530A or 1 DLPIAST_PHYIF_RS530 or 2 DLPIAST_PHYIF_X21 or 3 DLPIAST_PHYIF_V35 or 4 DLPIAST_PHYIF_RS449 or 5 DLPIAST_PHYIF_RS232 or 6 DLPIAST_PHYIF_HIZ or 7
phyIf
tc_purge_committed_data specifies whether the transmit BDs will be immediately purged of data when CTS/DCD go down. This parameter should be used in conjunction with tc_data_acks and tc_noclock_to to ensure that stale data is not left on the controller when CTS/DCD go back up. The preferred data purging mechanism is to use tc_noclock_to solely. This feature applies to xSTRa based platforms only. tc_encoding specifies the type of encoding for the link (NexusWare platforms only), which is defined by the following structure:
tc_idle_buf_to
this parameter determines the amount of time (in tenths of a second) allowed for transmission of an non 8-bit idle buffer when transmit data acknowledgements are enabled. This parameter applies to NexusWare based platforms only.
44
RDR_BIND_REQ
tp_bind_req_t Structure Parameters

The tp_bind_req_t structure defines the data part of the message for TPS-43 and TPS-75: tp_primitive conveys which variant of TPS-43: TPS43_A which consists of two start groups, fourteen data groups, and one odd parity group, TPS43_B and TPS43_D (also known as Link-1) which consists of one start group, 14 data groups (each with a mark bit), and one odd parity group, or TPS43_C (also known as Common Format) which consists of one start group, and one odd parity group in the middle of 14 data groups (each with a mark bit). This parameter is not used for TPS-75. identifies the DLSAP that will be bound to the connection. This parameter must have the same value as the rdr_link field in the control part of the message. specifies the line speed for the connection. A value of -1 for this parameter configures the link for external clocking, meaning that the transmit clock must be supplied by an external device (such as a modem). The receive clock signal is configured as an input (supplied by the transmitting device or other external device). For a normal receive-only connection, cd_baud should always be set to -1. tp_timeout_baud specifies the line speed in bits/second. For example, if the line speed is 2400 bps, tp_timeout_baud should be set to 2400. This value is used to calculate the time stamp for received messages. specifies the maximum length of a block of data which the TPS-43 or TPS-75 radar will divide up and build into data messages to transmit. Since the transmitted data messages are fixed in size (17 bytes for TPS-43 variant A, 16 bytes for TPS-43 variant B, variant C and variant D, and 18 bytes for TPS-75), the value for tp_maxmesg_size should be an even multiple of the data size. defines the maximum number of data messages that will be accumulated by the radar protocol module before they are forwarded to the radar mux. specifies the length of time, in increments of one hundred milliseconds, the radar protocol module waits before sending a block of received messages to the radar mux when tp_maxmesg_cnt has not been reached. determines the number of 8-bit bytes to be received before the data is processed (assembled into messages and forwarded to the application). Blocks of the specified size are received by the serial device driver and passed to a radar protocol module for processing. A very small block size decreases the efficiency of the serial device driver, while a large block size increases the latency of received messages. (The time stamp on each message is always accurate, regardless of the configured block size.)
tp_link
tp_baud
tp_maxmesg_size
tp_maxmesg_cnt
tp_fwd_time
tp_dma_blocksize
45
tp_contype
specifies RDR_READONLY for normal receive-only operation, RDR_WRITEONLY to transmit data, or RDR_READWRITE which allows reading and writing on the same link (QUICC platforms only). specifies the hexadecimal value of the start group (normally 0x68 for TPS43_A, 0x00 for TPS43_B, TPS43_C and TPS43_D, and 0x0000 for TPS-75). specifies the hexadecimal value of the character which the line will idle when no data is currently being transmitted (normally 0xAA for TPS43_A, 0x55 for both TPS43_B and TPS-75, and 0xFF for TPS43_C and TPS43_D). This parameter is only used when the tp_contype is set to RDR_READWRITE (see the parameter tp_contype, above). specifies how the SBSI driver should handle changes in modem input signals during link operation: RDR_NO_SIGS, changes in modem signals are ignored by the driver. RDR_SIGS, the driver will notify upstream modules when there is a change in modem input signals via a RDR_ERROR_IND with rdr_errno equal to either RDR_LINKUP or RDR_LINKDOWN.
tp_sync
tp_idle
tp_modem_in
tp_sigtimeout
specifies the amount of time (in10ms increments) to delay before processing a modem signal interrupt (normally referred to a debounce time). This parameter applies only if the tp_modem_in parameter is set to RDR_SIGS.
tp_relaxed_data_gathering specifies that unparsed data including SOM be sent up to client application (0 - off, 1 - on). phyIf The phyIf field configures the physical interface of a CPC358. It is ignored by all other products. The supported interfaces and their respective values are: V. 11 RS530A RS530 X.21 V.35 RS449 RS232 HIZ tp_error_info WANSTRPROT_PHYIF_V11 or 0 WANSTRPROT _PHYIF_RS530A or 1 WANSTRPROT _PHYIF_RS530 or 2 WANSTRPROT _PHYIF_X21 or 3 WANSTRPROT _PHYIF_V35 or 4 WANSTRPROT _PHYIF_RS449 or 5 WANSTRPROT _PHYIF_RS232 or 6 WANSTRPROT _PHYIF_HIZ or 7
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_REQ
tp_purge_committed_data specifies whether the transmit BDs will be immediately purged of data when CTS/DCD go down. This parameter should be used in conjunction with tp_data_acks and tp_noclock_to to ensure that stale data is not left on the controller when CTS/DCD go back up. The preferred data purging mechanism is to use tp_noclock_to solely. This feature applies to xSTRa based platforms only. tp_encoding Specifies the type of encoding for the link (NexusWare platforms only), which is defined by the following structure:
tp_idle_buf_to
This parameter determines the amount of time (in tenths of a second) allowed for transmission of an non 8-bit idle buffer when transmit data acknowledgements are enabled. This parameter applies to NexusWare based platforms only.
tp_enhanced
Specifies whether the TPS43_C variant should use the enhanced transmitter and receiver. The enhanced transmitter frames raw data into TPS43_C format for transmission (the raw data must have the final mark bit set). The enhanced receiver strips off framing bits before it passes the data to the application. Set this parameter to one to enable this feature or zero to disable.
raduga2_bind_req_t Structure Parameters

The raduga2_bind_req_t structure defines the data part of the message for Raduga-2: raduga2_primitive not used. raduga2_link identifies the DLSAP that will be bound to the connection. This parameter must have the same value as the rdr_link field in the control part of the message. 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_baud
47
raduga2_timeout_baud specifies the line speed in bits/second. For example, if the line speed is 9600 bps, raduga2_timeout_baud should be set to 9600. This value is used to calculate the time stamp for received messages. In the Toshiba radar protocol, this value is also used in conjunction with the desired time delay value (raduga2_fwd_time) to calculate how much idle padding to append to a transmitted message. raduga2_maxmesg_size specifies the number of bytes required to store the maximum length radar message in the selected data format. RDR uses this value to identify errors in received data and to format messages within the data portion of RDR_DATA_IND primitives. raduga2_maxmesg_cnt defines the maximum number of data messages that will be accumulated by the radar protocol module before they are forwarded to the radar mux. raduga2_fwd_time specifies the length of time, in increments of one hundred milliseconds, the radar protocol module waits before sending a block of received messages to the radar mux when raduga2_maxmesg_cnt has not been reached.
raduga2_dma_blocksize determines the number of 8-bit bytes to be received before the data is processed (assembled into messages and forwarded to the application). Blocks of the specified size are received by the serial device driver and passed to a radar protocol module for processing. A very small block size decreases the efficiency of the serial device driver, while a large block size increases the latency of received messages. (The time stamp on each message is always accurate, regardless of the configured block size.) raduga2_contype specifies RDR_READONLY for normal receive-only operation, RDR_WRITEONLY to transmit data, or RDR_READWRITE which allows reading and writing on the same link (QUICC platforms only). specifies the hexadecimal value of the start group. This would be the Barker Code (0x712) for Raduga-2 messages.
raduga2_sync
raduga2_check_crc at this moment, not used. raduga2_check_parity at this moment, not used. raduga2_modem_in specifies how the SBSI driver should handle changes in modem input signals during link operation: RDR_NO_SIGS, changes in modem signals are ignored by the driver. RDR_SIGS, the driver will notify upstream modules when there is a change in modem input signals via a RDR_ERROR_IND with rdr_errno equal to either RDR_LINKUP or RDR_LINKDOWN.
48
RDR_BIND_REQ
raduga2_sigtimeout specifies the amount of time (in 10ms increments) to delay before processing a modem signal interrupt (normally referred to a debounce time). This parameter applies only if the tp_modem_in parameter is set to RDR_SIGS. raduga2_do_idle specifies that the Radar Protocol should idle out the non 8-bit idle pattern defined in the raduga2_idle_pattern. If set, the protocol will construct the minimum sized buffer that will contain the non 8-bit idle pattern without padding to the end of a byte. This will be 240 bits (30 bytes) due to Raduga-2's 30-bit words. This is not applicable for links set to READONLY.
raduga2_idle_pattern user specified non 8-bit idle sequence (in lieu of the standard 8-bit idle character) for Raduga-2 when no radar data is being transmitted on the serial link. The intended idle patter for the Raduga-2 protocol is the Silence Message (0x3890800E). phyIf The phyIf field configures the physical interface of a CPC358. It is ignored by all other products. The supported interfaces and their respective values are: V. 11 RS530A RS530 X.21 V.35 RS449 RS232 HIZ WANSTRPROT_PHYIF_V11 or 0 WANSTRPROT _PHYIF_RS530A or 1 WANSTRPROT _PHYIF_RS530 or 2 WANSTRPROT _PHYIF_X21 or 3 WANSTRPROT _PHYIF_V35 or 4 WANSTRPROT _PHYIF_RS449 or 5 WANSTRPROT _PHYIF_RS232 or 6 WANSTRPROT _PHYIF_HIZ or 7
raduga2_purge_committed_data specifies whether the transmit BD's will be immediately purged of data when CTS/DCD go down. This parameter should be used in conjunction with raduga2_data_acks and raduga2_noclock_to to ensure that stale data is not left on the controller when CTS/DCD go back up. The preferred data purging mechanism is to use raduga2_noclock_to solely. This feature applies to xSTRa based platforms only. raduga2_encoding Specifies the type of encoding for the link (NexusWare platforms only), which is defined by the following structure:
49
raduga2_idle_buf_to This parameter determines the amount of time (in tenths of a second) allowed for transmission of an non 8-bit idle buffer when transmit data acknowledgements are enabled. This parameter applies to NexusWare based platforms only.
State
This message is valid in state RDR_UNBOUND.
New State
The resulting state is RDR_BIND_PENDING.
Response
When RDR successfully processes the bind request, it sends RDR_BIND_ACK to the application and the resulting state is RDR_DATAXFER. If the request is in error, RDR returns RDR_ERROR_ACK and the state reverts to RDR_UNBOUND.
Reasons for Failure

RDR_DLSAP_IN_USE RDR_INVALIDPORT RDR_NOSUCHPROTOCOL RDR_INVALID_BIND_PARAMS RDR_NOFREEUSCB The requested DLSAP is already bound to another connection. The specified DLSAP is invalid (out of range). The rdr_protocol string is invalid. Either the control part or data part Bind parameters structure is not of valid format. RDR cannot obtain the system resources necessary to complete the bind request.
50
RDR_BIND_ACK
RDR_BIND_ACK
This message is sent by RDR in response to a RDR_BIND_REQ to report the successful bind of a DLSAP to a connection. Once this response has been received, the station is in data transfer mode.
Message Format
The control part of this message is defined by the following structure: typedef struct { bit32 rdr_primitive; bit32 rdr_link; } rdr_bind_ack_t; There is no data part.
Parameters
rdr_primitive rdr_link conveys RDR_BIND_ACK. identifies the DLSAP that was bound.
State
This message is valid in state RDR_BIND_PENDING.
New State
The resulting state is RDR_DATAXFER.
51
RDR_UNBIND_REQ
This message is sent by an application to request RDR to unbind the DLSAP that was previously bound to the connection with a RDR_BIND_REQ.
Message Format
Parameters
rdr_primitive rdr_link conveys RDR_UNBIND_REQ. identifies the DLSAP.
State
This message is valid in state RDR_DATAXFER.
New State
The resulting state is RDR_UNBIND_PENDING.
Response
In response, RDR sends RDR_OK_ACK to the application, resulting in state RDR_UNBOUND. If the request is in error, RDR returns RDR_ERROR_ACK and the state is unchanged.
Reasons for Failure

RDR_NOTINIT RDR_INVALIDPORT The specified DLSAP is not currently bound to the connection. The specified DLSAP is invalid (out of range).
52
RDR_OK_ACK
RDR_OK_ACK
This message acknowledges to the application that a previously issued request primitive was processed successfully. It is only initiated for those primitives that require a positive acknowledgement.
Message Format
The control part of the message is defined by the following structure: typedef struct { bit32 rdr_primitive; bit32 rdr_correct_primitive; bit32 rdr_modifier; } rdr_ok_ack_t; There is no data part.
Parameters
rdr_primitive conveys RDR_OK_ACK. rdr_correct_primitive identifies the successfully received primitive that is being acknowledged. rdr_modifier identifies the DLSAP.
State
This message is valid from any of several states, in response to one of the following message types:
RDR_ATTACH_REQ RDR_DETACH_REQ RDR_UNBIND_REQ RDR_CLEAR_TICK
New State
The resulting state depends on the state from which the primitive was issued.
53
RDR_DATA_ACK
This message acknowledges to the application that a data request primitive was processed successfully.
Message Format
The control part of the message is defined by the following structure: typedef struct { bit32 bit32 bit32 struct utimeval wanStrPro_timeStatus_t } rdr_data_ack_t;
rdr_primitive; rdr_link; rdr_timestamp; rdr_sntp_timestamp; rdr_timeStatus;
If this message is due to a Data Acknowledgement (positive or negative) and Data Acknowledgements were setup to include the requested message (see the parameter rdr_data_acks of the Radar Protocol Bind request RDR_BIND_REQ on page 31), the data part will be that message. Else, there is no data part. This feature only applies to the NexusWare base Protocol controllers.
Parameters
rdr_primitive rdr_link rdr_timestamp conveys RDR_DATA_ACK. identifies the DLSAP. contains the time stamp (tick count), recorded at the time the message block was received.
rdr_sntp_timestamp contains the optional SNTP timestamp applied to received message blocks. This field only applies to certain models of PTI LAN-based servers. The timestamp is reported in a structure that consists of two fields: the number of seconds and the number of microseconds of Universal Coordinated Time (UTC). rdr_timeStatus specifies the external timestamp status if it is being used (see the parameter rdr_options1 in the RDR_BIND_REQ on page 31). This parameter is an enumeration and is treated as a bit field where more than one feature can be or'd together. This feature only applies to the NexusWare base Protocol controllers. The bit definitions are:
WANSTRPROT_TS_CLOCK_NOT_LOCKED (0x00000001)
indicates that the external clock's external synchronization signal is either unstable or missing.
WANSTRPROT_TS_CLOCK_NOT_SYNCED (0x00000002)
indicates that the external clock has not yet synchronized to the external synchronization signal.
54
RDR_DATA_ACK
WANSTRPROT_TS_CLOCK_INACCURATE (0x00000004)
indicates that the external clocks internal oscillator is not accurate and could indicate a hardware problem.
State
This message is valid in response to one of the following message types:
CD_DATA_REQ AS_DATA_REQ TC_DATA_REQ TP_DATA_REQ
New State
The resulting state depends on the state from which the primitive was issued.
55
RDR_ERROR_ACK
This message informs the application that the operation requested by a previously issued primitive failed.
Message Format
The control part of the message is defined by the following structure: typedef struct { bit32 bit32 bit32 bit32 bit32 struct utimeval wanStrPro_timeStatus_t } rdr_error_ack_t;
rdr_primitive; rdr_error_primitive; rdr_errno; rdr_modifier; rdr_timestamp; rdr_sntp_timestamp; rdr_timeStatus;
If this message is due to a Data Acknowledgement (positive or negative) and Data Acknowledgements were setup to include the requested message (see the parameter rdr_data_acks of the Radar Protocol Bind request RDR_BIND_REQ on page 31), the data part will be that message. Else, there is no data part. This feature only applies to the NexusWare base Protocol controllers.
Parameters
rdr_primitive conveys RDR_ERROR_ACK. rdr_error_primitive identifies the primitive in error. rdr_errno rdr_modifier rdr_timestamp conveys the DLPI error code associated with the failure. See the individual primitive for the error codes that are applicable. identifies the DLSAP. contains the time stamp (tick count), recorded at the time the message block was received.
rdr_sntp_timestamp contains the optional SNTP timestamp applied to received message blocks. This field only applies to certain models of PTI LAN-based servers. The timestamp is reported in a structure that consists of two fields: the number of seconds and the number of microseconds of Universal Coordinated Time (UTC). rdr_timeStatus specifies the external timestamp status if it is being used (see the parameter rdr_options1 in the RDR_BIND_REQ on page 31). 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
indicates that the external clocks internal oscillator is not accurate and could indicate a hardware problem.
State
The message is valid in every state where an acknowledgement or confirmation of a previous request or response is pending.
New State
The resulting state is that from which the acknowledged primitive was generated.
57
RDR_ERROR_IND
This message informs the application that the serial link associated with the connection is not operating correctly. After sending this primitive, RDR continues to monitor the serial link, and automatically returns to normal operation when valid data is received.
Message Format
The control part of this message is defined by the following structure: typedef struct { bit32 rdr_primitive; bit32 rdr_link; bit32 rdr_errno; } rdr_error_ind_t; There is no data part.
Parameters
rdr_primitive rdr_link rdr_errno conveys RDR_ERROR_IND. identifies the DLSAP. identifies the error condition. The following error codes are possible: CD_EMSGSIZE More than the configured maximum number of bytes per message were received without detecting an idle character to terminate the message. This error can only occur on a link configured for CD-2 (FPS 117), Marconi 10-Bit, Modified Eurocontrol, General 18-Bit or NEC Radar Extractor. The receiver lost synchronization on the serial link. (When this error occurs, RDR automatically attempts to reestablish synchronization.) This error can only occur on a link configured for CD2 (FPS 117), Marconi 10-Bit, Modified Eurocontrol or General 18-Bit. More than the configured maximum number of bytes per message were received without detecting an ETX character to terminate the message. This error can only occur on a link configured for Thompson-CSF, Thompson-TVT2 or Toshiba.
CD_ECOMM
TC_EMSGSIZE
RADUGA2_EMSGSIZE The current Raduga-2 message that is being received has more than 5 30-bit words defined as its length.
58
RDR_ERROR_IND
AS_LINKDOWN AS_LINKUP RDR_CTS_UP
The receiver has lost link (connection) on the serial link. The receiver has a link condition (connection) on the serial link. Clear to Send Changes state from disabled to enabled. This error can only occur when either the cd_modem_in, tp_modem_in, or tc_modem _in parameter from the corresponding bind structure is set to RDR_SIGS. Clear to Send changes state from enabled to disabled. This error can only occur when either the cd_modem_in, tp_modem_in, or tc_modem _in parameter from the corresponding bind structure is set to RDR_SIGS.
RDR_CTS_DOWN
RDR_BAD_MARKBIT indicates 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. Data Carrier Detect changes state from disabled to enabled. This error can only occur when either the cd_modem_in, tp_modem_in, tc_modem_in or raduga2_modem_in parameter from the corresponding bind structure is set to RDR_SIGS. Data Carrier Detect changes state from enabled to disabled. This error can only occur when either the cd_modem_in, tp_modem_in, tc_modem_in or raduga2_modem_in parameter from the corresponding bind structure is set to RDR_SIGS.
RDR_DCD_UP
RDR_DCD_DOWN
State
New State
The resulting state is unchanged.
59
RDR_CLEAR_TICK
An application sends this message to RDR to clear the system tick counter, which is used to time stamp received messages. Since the system maintains a single, global tick counter for each communication controller, this primitive affects the time stamp for subsequent received messages on all serial links of a given controller. Note: This primitive applies to xSTRa-based platforms only.
Message Format
Parameters
rdr_primitive rdr_link conveys RDR_CLEAR_TICK. identifies the DLSAP.
State
This message is valid in any state.
New State
Response
RDR responds to this request with RDR_OK_ACK. If the request is in error, RDR returns RDR_ERROR_ACK instead.
Reasons for Failure

RDR_INVALIDPORT The specified DLSAP is invalid (out of range).
60
CD_STATISTICS_REQ
CD_STATISTICS_REQ
An application sends this message to RDR to request data transfer statistics for a serial link configured for the CD-2 (FPS 117), Marconi 10-Bit, Modified Eurocontrol, General 18 bit or NEC Radar Extractor radar data format.
Message Format
Parameters
rdr_primitive rdr_link conveys CD_STATISTICS_REQ. identifies the serial link (DLSAP) for which statistical information is requested.
State
New State
Response
RDR responds to this request with CD_STATISTICS_ACK. If the request is in error, RDR returns RDR_ERROR_ACK instead.
Reasons for Failure

61
CD_STATISTICS_ACK
RDR sends this message in response to CD_STATISTICS_REQ.
Message Format
The control part of the message is defined by the following structure: typedef struct { bit32 rdr_primitive; bit32 rdr_link; } rdr_primitive; See rdr_primitive Structure Parameters on page 62 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 63 for a description of each parameter.
Parameters
rdr_primitive Structure Parameters
In the rdr_primitive structure: rdr_primitive rdr_link conveys CD_STATISTICS_ACK. identifies the DLSAP to which the statistical information applies.
62
CD_STATISTICS_ACK
cd_statistics_t Structure Parameters

The cd_statistics_t structure contains event counts for the connection associated with the specified serial link, as follows: cd_recv_msgs cd_recv_2big cd_sync_lost cd_recv_orun cd_no_timers cd_no_buffers cd_bad_mtype cd_recv_borun cd_xmit_msgs cd_no_clocks cd_data_acks total number of received messages since the connection was established. number of times the maximum message size configured for the connection was exceeded. number of times synchronization on the serial link was lost. number of receive overruns. number of times the data-forwarding timer could not be initiated due to a shortage of system resources. number of times the radar protocol module was required to retry an attempt to obtain a data buffer for received data. number of unrecognized message types (non-protocol messages) received from the connected application. number of received data buffers overwritten due to lack of memory resources. total number of messages transmitted since the connection was established (diagnostic connection only). number of times the serial device driver failed to forward any data (due to lack of clocks). total number of data acknowledgements received in response to a DATA_REQ primitive.
State
New State
63
AS_STATISTICS_REQ
An application sends this message to RDR to request data transfer statistics for a serial link configured for the ASTERIX radar data format.
Message Format
Parameters
rdr_primitive rdr_link conveys AS_STATISTICS_REQ. identifies the serial link (DLSAP) for which statistical information is requested.
State
New State
Response
RDR responds to this request with AS_STATISTICS_ACK. If the request is in error, RDR returns RDR_ERROR_ACK instead.
Reasons for Failure

64
AS_STATISTICS_ACK
AS_STATISTICS_ACK
RDR sends this message in response to AS_STATISTICS_REQ.
Message Format
The control part of the message is defined by the following structure: typedef struct { bit32 rdr_primitive; bit32 rdr_link; } rdr_primitive; See rdr_primitive Structure Parameters on page 65 for a description of each parameter. The statistics information is contained in the data part of the message, which is defined by the following structure: typedef struct { bit32 as_xgood; bit32 as_rgood; bit32 as_xunder; bit32 as_rover; bit32 as_rtoo; bit32 as_rcrc; bit32 as_rabt; bit32 as_no_clocks; bit32 as_data_acks; bit32 as_corrupt_msgs; } as_statistics_t; See as_statistics_t Structure Parameters on page 65 for a description of each parameter.
Parameters
In the rdr_primitive structure: rdr_primitive rdr_link conveys AS_STATISTICS_ACK. identifies the DLSAP to which the statistical information applies.
as_statistics_t Structure Parameters

The as_statistics_t structure contains event counts for the connection associated with the specified serial link, as follows: as_xgood total number of messages transmitted since the connection was established.
65
as_rgood as_xunder as_rover as_rtoo as_rcrc as_rabt as_no_clocks as_data_acks as_corrupt_msgs
total number of received messages since the connection was established. not used (always zero). number of receive overruns. number of times the maximum message size configured for the connection was exceeded. number of CRC (frame check sequence) errors. number of aborted frames. number of times the serial device driver failed to forward any data (due to lack of clocks). total number of data acknowledgements receieved in response to a DATA_REQ primitive. number of corrupt messages transmitted. This occurs if the message was not completely transmitted due to an error.
State
New State
66
TC_STATISTICS_REQ
TC_STATISTICS_REQ
An application sends this message to RDR to request data transfer statistics for a serial link configured for Thompson-CSF, Thompson-TVT2 or Toshiba radar data format.
Message Format
Parameters
rdr_primitive rdr_link conveys TC_STATISTICS_REQ. identifies the serial link (DLSAP) for which statistical information is requested.
State
New State
Response
RDR responds to this request with TC_STATISTICS_ACK. If the request is in error, RDR returns RDR_ERROR_ACK instead.
67
TC_STATISTICS_ACK
RDR sends this message in response to TC_STATISTICS_ACK.
Message Format
The control part of the message is defined by the following structure: typedef struct { bit32 rdr_primitive; bit32 rdr_link; } rdr_primitive; See rdr_primitive Structure Parameters on page 68 for a description of each parameter. The statistics information is contained in the data part of the message, which is defined by the following structure: typedef struct { bit32 tc_recv_msgs; bit32 tc_xmit_msgs; bit32 tc_recv_2big; bit32 tc_xmit_2big; bit32 tc_recv_orun; bit32 tc_no_timers; bit32 tc_no_buffers; bit32 tc_bad_bcc; bit32 tc_bad_mtype; bit32 tc_recv_borun; bit32 tc_no_clocks; bit32 tc_data_acks; } tc_statistics_t; See tc_statistics_t Structure Parameters on page 68 for a description of each parameter.
Parameters
In the rdr_primitive structure: rdr_primitive rdr_link conveys TC_STATISTICS_REQ. identifies the DLSAP to which the statistical information applies.
tc_statistics_t Structure Parameters

The tc_statistics_t structure contains event counts for the connection associated with the specified serial link, as follows:
68
TC_STATISTICS_ACK
tc_recv_msgs tc_xmit_msgs tc_recv_2big tc_xmit_2big tc_recv_orun tc_no_timers tc_no_buffers tc_bad_bcc tc_bad_mtype tc_recv_borun tc_no_clocks tc_data_acks
total number of received messages since the connection was established. total number of messages transmitted since the connection was established. number of times the maximum receive message size configured for the connection was exceeded. number of times the maximum transmit message size configured for the connection was exceeded. number of receive overruns. number of times the data-forwarding timer could not be initiated due to a shortage of system resources. number of times received data was discarded because memory was not available. number of messages discarded due to block check errors. number of unrecognized message types (non-protocol messages) received from the connected application. number of received data buffers overwritten due to lack of memory resources number of times the serial device driver failed to forward any data (due to lack of clocks). total number of data acknowledgements received in response to DATA_REQ primitive.
State
New State
69
TP_STATISTICS_REQ
An application sends this message to RDR to request data transfer statistics for a serial link configured for the TPS-43 or TPS-75 radar data formats.
Message Format
Parameters
rdr_primitive rdr_link conveys TP_STATISTICS_REQ. identifies the serial link (DLSAP) for which statistical information is requested.
State
New State
Response
RDR responds to this request with TP_STATISTICS_ACK. If the request is in error, RDR returns RDR_ERROR_ACK instead.
70
TP_STATISTICS_ACK
TP_STATISTICS_ACK
RDR sends this message in response to TP_STATISTICS_ACK.
Message Format
The control part of the message is defined by the following structure: typedef struct { bit32 rdr_primitive; bit32 rdr_link; } rdr_primitive; See rdr_primitive Structure Parameters on page 71 for a description of each parameter. The statistics information is contained in the data part of the message, which is defined by the following structure: typedef struct { bit32 tp_recv_msgs; bit32 tp_xmit_msgs; bit32 tp_recv_2big; bit32 tp_xmit_2big; bit32 tp_recv_orun; bit32 tp_no_timers; bit32 tp_no_buffers; bit32 tp_bad_mtype; bit32 tp_recv_borun; bit32 tp_bad_parity; bit32 tp_xmt_rjct; bit32 tp_no_clocks; bit32 tp_data_acks; bit32 tp_bad_mbit } tp_statistics_t; See tp_statistics_t Structure Parameters on page 72 for a description of each parameter.
Parameters
In the rdr_primitive structure: rdr_primitive rdr_link conveys TP_STATISTICS_REQ. identifies the DLSAP to which the statistical information applies.
71
tp_statistics_t Structure Parameters

The tp_statistics_t structure contains event counts for the connection associated with the specified serial link, as follows: tp_recv_msgs tp_xmit_msgs tp_recv_2big tp_xmit_2big tp_recv_orun tp_no_timers tp_no_buffers tp_bad_mtype tp_recv_borun tp_bad_parity tp_xmt_rjct tp_no_clocks tp_data_acks tp_bad_mbit total number of received messages since the connection was established. total number of messages transmitted since the connection was established. number of times the maximum receive message size configured for the connection was exceeded. number of times the maximum transmit message size configured for the connection was exceeded. number of receive overruns. number of times the data-forwarding timer could not be initiated due to a shortage of system resources. number of times received data was discarded because memory was not available. number of unrecognized message types (non-protocol messages) received from the connected application. number of received data buffers overwritten due to lack of memory resources. number of received messages discarded due to parity errors or mark bit errors (if TPS43_B, TPS43_C, TPS43_D or TPS-75). number of transmitted messages discarded due to the message size not being an even multiple of the data size. number of times the serial device driver failed to forward any data (due to lack of clocks). total number of data acknowledgements received in response to a DATA_REQ primitive. number of transmit messages discarded due to the final mark bit not being set.
State
New State
72
RADUGA2_STATISTICS_REQ
RADUGA2_STATISTICS_REQ
An application sends this message to RDR to request data transfer statistics for a serial link configured for the Raduga-2 radar data formats.
Message Format
Parameters
rdr_primitive rdr_link conveys RADUGA2_STATISTICS_REQ. identifies the serial link (DLSAP) for which statistical information is requested.
State
New State
Response
RDR responds to this request with RADUGA2_STATISTICS_ACK. If the request is in error, RDR returns RDR_ERROR_ACK instead.
73
RADUGA2_STATISTICS_ACK
RDR sends this message in response to RADUGA2_STATISTICS_ACK.
Message Format
The control part of the message is defined by the following structure: typedef struct { bit32 rdr_primitive; bit32 rdr_link; } rdr_primitive; See rdr_primitive Structure Parameters on page 74 for a description of each parameter. The statistics information is contained in the data part of the message, which is defined by the following structure: typedef struct { bit32 raduga2_recv_msgs; bit32 raduga2_xmit_msgs; bit32 raduga2_recv_2big; bit32 raduga2_xmit_2big; bit32 raduga2_recv_orun; bit32 raduga2_no_timers; bit32 raduga2_no_buffers; bit32 raduga2_bad_mtype; bit32 raduga2_recv_borun; bit32 raduga2_no_clocks; bit32 raduga2_data_acks; bit32 raduga2_num_parity; bit32 raduga2_bad_msg_lngth; bit32 raduga2_num_crc; bit32 raduga2_bad_mark_bit; bit32 raduga2_xmit_rjct; } raduga2_statistics_t;
/* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /*
Total messages received Total xmt messages Recv messages too big Xmit message too big Receive overruns Forward timer failures Buffer alloc failures Unknown STREAMS type Receive buffer overruns No data due to no clocks # Data Acks sent up stream # Message parity errors # Message Length errors # CRC (Control Pattern) errors # Mark bit errors # Transmit Data Req rejected.
*/ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */
See raduga2_statistics_t Structure Parameters on page 75 for a description of each parameter.
Parameters
In the rdr_primitive structure: rdr_primitive conveys RADUGA2_STATISTICS_REQ.
74
RADUGA2_STATISTICS_ACK
rdr_link
identifies the DLSAP to which the statistical information applies.
raduga2_statistics_t Structure Parameters

The raduga2_statistics_t structure contains event counts for the connection associated with the specified serial link, as follows: raduga2_recv_msgs total number of received messages since the connection was established. raduga2_xmit_msgs total number of messages transmitted since the connection was established. raduga2_recv_2big number of times the maximum receive message size configured for the connection was exceeded. raduga2_xmit_2big number of times the maximum transmit message size configured for the connection was exceeded. raduga2_recv_orun number of receive overruns. raduga2_no_timers number of times the data-forwarding timer could not be initiated due to a shortage of system resources. raduga2_no_buffers number of times received data was discarded because memory was not available. raduga2_bad_mtype number of unrecognized message types (non-protocol messages) received from the connected application. raduga2_recv_borun number of received data buffers overwritten due to lack of memory resources. raduga2_no_clocks number of times the serial device driver failed to forward any data (due to lack of clocks). raduga2_data_acks total number of data acknowledgements received in response to a DATA_REQ primitive. raduga2_num_parity number of received messages discarded due to parity errors. raduga2_bad_msg_lngth number of received messages discarded due to invalid message length. raduga2_num_crc number of received messages discarded due CRC (Control Pattern) errors.
raduga2_bad_mark_bit number of received messages discarded due to mark bit errors raduga2_xmt_rjct currently not used.
75
State
New State
76
CD_DATA_REQ
CD_DATA_REQ
An application uses this primitive to send a block of data to RDR for transmission on a serial link configured for the CD-2 (FPS 117), Marconi 10-Bit, Modified Eurocontrol, General 18-Bit or NEC Radar Extractor radar data format. The link must be configured in diagnostic mode. RDR guarantees to transmit each block in the same order as received from the application. When the data supplied with a CD_DATA_REQ has been completely transmitted and another CD_DATA_REQ is available for processing, RDR will begin transmitting the next block of data without interruption. If no new data is available for transmission and the protocol is not the NEC Radar Extractor, the serial line will transmit the non 8-bit idle sequence specified by the bind parameters cd_idle_pattern and if the bind parameter cd_do_idle has been set.
Message Format
The control part of the message is defined by the following structure: typedef struct { bit32 cd_primitive; bit32 cd_link; bit32 cd_noclock_to; } cd_data_req_t; The data part of the message contains the block of data to be transmitted.
Parameters
cd_primitive cd_link cd_noclock_to conveys CD_DATA_REQ. identifies the serial link (DLSAP) on which the block of data is to be transmitted. applies only if acknowledgements are configured for the link (see the parameter rdr_data_acks in the RDR_BIND_REQ on page 31 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.
CD-2 (FPS 117) Data Format

The data, in the data part of the message, can be formatted as a packed or an unpacked bit stream, depending on the setting of the cd_xmt_unpackmesg parameter. In the packed format, the first two bytes of data contain the first 13-bit word and three bits of the second word. The most-significant bit of the first word is in the most significant bit of the first byte. The three leastsignificant bits of the second byte contain the three most-significant bits of the second word, and so on.
77
On the serial line, each 13-bit word is transmitted most-significant bit first. The total number of data bytes must be calculated so that the block ends on a 13-bit word boundary if the cd_xmt_idles parameter is not set. That is, the last data byte must contain the low-order eight bits of a 13-bit word. This is not necessary if the cd_xmt_idles parameter is set. Packed CD-2 data is shown in the diagram below, where each 13-bit word is shown as a string of alphabetic characters, with the most-significant bit of the word in upper case. Byte 1
Aaaaaaaa
Byte 2
aaaaaBbb
Byte 3
bbbbbbbb
Byte 4
bbCccccc
In the unpacked format, the message data is contained in an array of chars. Each pair of chars will contain one message word. The five most significant bits of each message word will be contained in the five least significant bits of the first char. The other bits of the first char are not used. The 8 least significant bits of each message word are contained in the second char. If configured as unpacked, the CD-2 protocol will convert the data to a packed bit stream before being transmitted. On the serial line, each 13-bit word is transmitted most-significant bit first. The total number of data bytes (that is, after the conversion to packed data) must be calculated so that the block ends on a 13-bit word boundary if the cd_xmt_idles parameter is not set. That is, the last data byte must contain the low-order eight bits of a 13-bit word. This is not necessary if the cd_xmt_idles parameter is set. Unpacked CD-2 data is shown in the diagram below, where each 13-bit word is shown as a string of alphabetic characters, with the mostsignificant bit of the word in upper case. The zero value indicates unused. Byte 1
000Aaaaa
Byte 2
aaaaaaaa
Byte 3
000Bbbbb
Byte 4
bbbbbbbb
Idle words will be included between messages if the cd_xmt_idles parameter is set. If the cd_xmt_idles parameter is not set, it is assumed that each radar message within the data is separated by at least one 13-bit idle character, with at least one idle character following the last message in the block.
Marconi 10-Bit Data Format

The data, in the data part of the message, can be formatted as a packed or an unpacked bit stream, depending on the setting of the cd_xmt_unpackmesg parameter. In the packed format, the first two bytes of data contain the first 10-bit word and six bits of the second word. The least-significant bit of the first word is in the most significant bit of the first byte. The six leastsignificant bits of the second byte contain the six least-significant bits of the second word, and so on.
78
CD_DATA_REQ
On the serial line, each 10-bit word is transmitted least-significant bit first. The total number of data bytes must be calculated so that the block ends on a 10-bit word boundary if the cd_xmt_idles parameter is not set. That is, the last data byte must contain the high-order eight bits of a 10-bit word. This is not necessary if the cd_xmt_idles parameter is set. Packed Marconi data is shown in the diagram below, where each 10-bit word is shown as a string of alphabetic characters, with the most-significant bit of the word in upper case. Byte 1
aaaaaaaa
Byte 2
aAbbbbbb
Byte 3
bbbBcccc
Byte 4
cccccCdd
In the unpacked format, the message data is contained in an array of chars. Each pair of chars will contain one message word. The two least significant bits of each message word will be contained in the two least significant bits of the first char. The other bits of the first char are not used. The 8 most significant bits of each message word are contained in the second char. If configured as unpacked, the Marconi protocol will convert the data to a packed bit stream before being transmitted. On the serial line, each 10-bit word is transmitted least-significant bit first. The total number of data bytes (that is, after the conversion to packed data) must be calculated so that the block ends on a 10-bit word boundary if the cd_xmt_idles parameter is not set. That is, the last data byte must contain the high-order eight bits of a 10-bit word. This is not necessary if the cd_xmt_idles parameter is set. Unpacked Marconi data is shown in the diagram below, where each 10-bit word is shown as a string of alphabetic characters, with the most-significant bit of the word in upper case. The zero value indicates unused. Byte 1
000000aa
Byte 2
aaaaaaaA
Byte 3
000000bb
Byte 4
bbbbbbbB
Idle words will be included between messages if the cd_xmt_idles parameter is set as well as STX and ETX at the start and stop of each message. If the cd_xmt_idles parameter is not set, it is assumed that each radar message within the data is separated by at least one 10-bit idle character, with at least one idle character following the last message in the block and each message is framed with STX and ETX.
Modified Eurocontrol and General 18-Bit Data Format

The data, in the data part of the message, can be formatted as a packed or an unpacked bit stream, depending on the setting of the cd_xmt_unpackmesg parameter. In the packed format, the first three bytes of data contain the first 18-bit word and six bits of the second word. The most-significant bit of the first word is in the most significant bit of the first byte. The six leastsignificant bits of the third byte contain the six most-significant bits of the second word, and so on.
79
On the serial line, each 18-bit word is transmitted most-significant bit first. The total number of data bytes must be calculated so that the block ends on a 18-bit word boundary if the cd_xmt_idles parameter is not set. That is, the last data byte must contain the low-order eight bits of a 18-bit word. This is not necessary if the cd_xmt_idles parameter is set. Packed Modified Eurocontrol and General 18-bit data is shown in the diagram below, where each 18-bit word is shown as a string of alphabetic characters, with the most-significant bit of the word in upper case. Byte 1
Aaaaaaaa
Byte 2
aaaaaaaa
Byte 3
aaBbbbbb
Byte 4
bbbbbbbb
Byte5
bbbbCccc
In the unpacked format, the message data is contained in an array of chars. Four chars will contain one message word. The two most significant bits of each message word will be contained in the two least significant bits of the second char. The other bits of the first and second char are not used. The 8 least significant bits of each message word are contained in the fourth char. If configured as unpacked, the Modified Eurocontrol and General 18-bit protocols will convert the data to a packed bit stream before being transmitted. On the serial line, each 18-bit word is transmitted most-significant bit first. The total number of data bytes (that is, after the conversion to packed data) must be calculated so that the block ends on a 18-bit word boundary if the cd_xmt_idles parameter is not set. That is, the last data byte must contain the low-order eight bits of a 18-bit word. This is not necessary if the cd_xmt_idles parameter is set. Unpacked Modified Eurocontrol and General 18-bit data is shown in the diagram below, where an 18-bit word is shown as a string of alphabetic characters, with the most-significant bit of the word in upper case. The zero value indicates unused. Byte 1
00000000
Byte 2
000000Aa
Byte 3
aaaaaaaa
Byte 4
aaaaaaaa
Idle words will be included between messages if the cd_xmt_idles parameter is set. If the cd_xmt_idles parameter is not set, it is assumed that each radar message within the data is separated by at least one 18-bit idle character, with at least one idle character following the last message in the block.
NEC Radar Extractor Data Format

The data, in the data part in the message, must be completely formatted as a NEC Radar Extractor packet. The first bit of the first byte of the data must have a value of 1 to signify Start of Message. The last byte of the data packet must be the value 0x00 to signify End of Message. Byte 1
1aaaaaaa
Byte 2
Bbbbbbbb
Byte 3
Cccccccc ...
Byte N
00000000
State
80
AS_DATA_REQ
New State
Response
There is no response unless data acknowledgements are enabled, in which case RDR returns RDR_DATA_ACK or the request fails, in which case RDR returns RDR_ERROR_ACK.
Reasons for Failure

ENOLINK EACCESS RDR_DATA_TIMEDOUT RDR_BAD_DATA_FORMAT RDR_BAD_DATA_BLOCK No DLSAP is bound to the connection. The connection is not configured for diagnostic mode. Failed to transmit message before timeout value. The control structure is not of valid format. The data part of the request does not exist.
AS_DATA_REQ
An application uses this primitive to send a block of data to RDR for transmission on a serial link configured for the ASTERIX radar data format. The data supplied will be sent as a single HDLC frame. The frame must be completely formatted by the sending application. RDR adds only the opening and closing flags and appends the two-byte CRC. RDR guarantees to transmit each block in the same order as received from the application. The serial line idles flags (0x7E) between frames.
Message Format
The control part of the message is defined by the following structure: typedef struct { bit32 as_primitive; bit32 as_link; bit32 as_noclock_to; } as_data_req_t; The data part of the message contains the block of data to be transmitted as an HDLC frame.
Parameters
as_primitive as_link conveys AS_DATA_REQ. identifies the serial link (DLSAP) on which the block of data is to be transmitted.
81
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 31 primitive.) This parameter determines the amount of time (in tenths of a second) allowed for transmission of the message. If the message is successfully transmitted prior to expiration of the specified time, the application will receive a RDR_DATA_ACK confirming transmission. If the message is not successfully transmitted before this time expires, the transmission is aborted, and a RDR_ERROR_ACK is returned with the rdr_errno field set to RDR_DATA_TIMEOUT. If this parameter is zero, this function is disabled.
State
New State
Response
Reasons for Failure

ENOLINK RDR_DATA_TIMEDOUT No DLSAP is bound to the connection. Failed to transmit message before timedout value.
82
TC_DATA_REQ
TC_DATA_REQ
An application uses this primitive to send a block of data to RDR for transmission on a serial link either configured for the Thompson-CSF radar data format, the Thompson-TVT2 radar data format or the Toshiba radar data format. The link must be configured in diagnostic mode. The data supplied will be sent as a single Thompson-CSF, Thompson-TVT2 or Toshiba radar message.
Thompson-CSF Data Format

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

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

For Toshiba, the RDR formats the message for transmission as follows:
Two sync characters are added to the start of the message. A DLE-STX control sequence is added to signify start of data. DLE control sequences are added to the data as required for transparency. A DLE-ETX control sequence is added at the end of the data. The 16-bit BCC is calculated for transmission following the DLE-ETX sequence.
If the resulting radar message that was produced with the data supplied in the TC_DATA_REQ request exceeds the maximum data size for the link, the request will be rejected, and the appropriate statistic (recv_2big) will be incremented. RDR guarantees to transmit each block in the same order as received from the application. When the data supplied with a TC_DATA_REQ has been completely transmitted and another TC_DATA_REQ is available for processing, RDR will begin transmitting the next block of data without interruption. If no new data is available for transmission, the serial line will idle ones (characters with the value 0xFF).
83
Message Format
The control part of the message is defined by the following structure: typedef struct { bit32 tc_primitive; bit32 tc_link; bit32 tc_noclock_to; bit8 tc_hdr1; bit8 tc_hdr2; } tc_data_req_t; The data part of the message contains the block of data to be transmitted in the data portion of the radar message.
Parameters
tc_primitive tc_link tc_noclock_to conveys TC_DATA_REQ. identifies the serial link (DLSAP) on which the block of data is to be transmitted. applies only if acknowledgements are configured for the link (see the parameter rdr_data_acks in the RDR_BIND_REQ on page 31 primitive.) This parameter determines the amount of time (in tenths of a second) allowed for transmission of the message. If the message is successfully transmitted prior to expiration of the specified time, the application will receive a RDR_DATA_ACK confirming transmission. If the message is not successfully transmitted before this time expires, the transmission is aborted, and a RDR_ERROR_ACK is returned with the rdr_errno field set to RDR_DATA_TIMEOUT. If this parameter is zero, this function is disabled. contains the value to be transmitted in the first byte of the two-byte header. For Toshiba Radar, this value is not used. contains the value to be transmitted in the second byte of the two-byte header. For Toshiba Radar, this value is not used. Byte 1
1aaaaaaa
tc_hdr1 tc_hdr2
Byte 2
Bbbbbbbb
Byte 3
Cccccccc
Byte 4
Dddddddd
State
New State
84
TC_DATA_REQ
Response
There is no response unless data acknowledgements are enabled, in which case RDR returns RDR_DATA_ACK or if the request fails, in which case RDR returns RDR_ERROR_ACK.
Reasons for Failure

85
TP_DATA_REQ
An application uses this primitive to send a block of data to RDR for transmission on a serial link configured for the TPS-43 or TPS-75 radar data format. The link must be configured in diagnostic mode. The data supplied will be divided into n 14 byte sized data blocks, or 16 byte sized data blocks for TPS43_C. Each data block will then be sent as a TPS-43 or TPS-75 radar message. If the total data size is not divisible by 14 (or 16 for TPS43_C), the remaining data will be rejected, and an informational statistic (tp_xmt_rjct) will be incremented.
TPS43_A
The RDR formats a TPS43_A variant radar message for transmission as follows:
Two start groups are added to the beginning of the message. A parity group (odd parity of the preceding 16 groups) is added to the end of the message.
TPS43_B
For a TPS43_B variant radar message, the RDR assumes that each data group has the proper mark bit set. The RDR formats a TPS43_B variant radar message for transmission as follows:
One start group is added to the beginning of the message. A parity group (odd parity of the preceding 14 groups) is added to the end of the message.
TPS43_C
For a TPS43_C variant radar message (besides Enhanced TPS43_C described below), the RDR assumes that each message to send out has one start group at the beginning of the message followed by 14 data groups with a parity group (odd parity) in the middle, all with the proper mark bit set for each group.
Enhanced TPS43_C
For an Enhanced TPS43_C radar message, all formatting of a 98 bit message will be done by the transmitter (the final mark bit must be set for each message in the raw data or the message will be rejected). Since a 98 bit message does not fall on an 8 bit boundary, the last message bundled to be sent must be padded out with zeros to the next byte boundary. No padding is expected between back-to-back messages.
TPS43_D
For a TPS43_D variant radar message, the RDR assumes that each data group has the proper mark bit set. The RDR formats a TPS43_D variant radar message for transmission as follows:
One start group is added to the beginning of the message. A parity group (odd parity of the preceding 14 groups, which consists of a single, fixed bit, followed by 6 check bits, followed by a final bit) is added to the end of the message.
86
TP_DATA_REQ
TPS-75
For a TPS-75 radar message, the RDR formats a radar message for transmission as follows:
One start group is added to the beginning of the message. One mark bit is added to each of the 14 data groups. A parity group (odd parity of the preceding 14 data groups) is added to the end of the message.
If the resulting radar messages that were produced with the data supplied in the TP_DATA_REQ request exceeds the maximum data size for the link, the request will be rejected, and the appropriate statistic (tp_xmit_2big) will be incremented. RDR guarantees to transmit each block in the same order as received from the application. When the data supplied with a TP_DATA_REQ has been completely transmitted and another TP_DATA_REQ is available for processing, RDR will begin transmitting the next block of data without interruption. If no new data is available for transmission, the serial line will idle the idle character which was specified in the bind request (tp_idle).
Message Format
The control part of the message is defined by the following structure: typedef struct { bit32 tp_primitive; bit32 tp_link; bit32 tp_noclock_to; } tp_data_req_t; The data part of the message contains the block of data to be transmitted in the data portion of the radar message.
Parameters
tp_primitive tp_link tp_noclock_to conveys TP_DATA_REQ. identifies the serial link (DLSAP) on which the block of data is to be transmitted. applies only if acknowledgements are configured for the link (see the parameter rdr_data_acks in the RDR_BIND_REQ on page 31 primitive.) This parameter determines the amount of time (in tenths of a second) allowed for transmission of the message. If the message is successfully transmitted prior to expiration of the specified time, the application will receive a RDR_DATA_ACK confirming transmission. If the message is not successfully transmitted before this time expires, the transmission is aborted, and a RDR_ERROR_ACK is returned with the rdr_errno field set to RDR_DATA_TIMEOUT. If this parameter is zero, this function is disabled.
State
87
New State
Response
Reasons for Failure

88
RADUGA2_DATA_REQ
RADUGA2_DATA_REQ
An application uses this primitive to send a block of data to RDR for transmission on a serial link configured for the Raduga-2 radar data format. The link must be configured in RDR_WRITEONLY or RDR_READWRITE mode. The data supplied will be used as the payload section for the applicable Raduga-2 30-bit word messages that get generated based on the Message Length and Message Identifiers values.
Message Format
The control part of the message is defined by the following structure: typedef struct { bit32 raduga2_primitive; bit32 raduga2_link; bit32 raduga2_noclock_to; bit32 raduga2_message_length; bit32 raduga2_message_identifier; } raduga2_data_req_t; The data part of the message contains the block of data to be transmitted in the data portion of the radar message.
Parameters
raduga2_primitive conveys RADUGA2_DATA_REQ. raduga2_link identifies the serial link (DLSAP) on which the block of data is to be transmitted.
raduga2_noclock_to applies only if acknowledgements are configured for the link (see the parameter rdr_data_acks in the RDR_BIND_REQ on page 31 primitive). This parameter determines the amount of time (in tenths of a second) allowed for transmission of the message. If the message is successfully transmitted prior to expiration of the specified time, the application will receive a RDR_DATA_ACK confirming transmission. If the message is not successfully transmitted before this time expires, the transmission is aborted, and a RDR_ERROR_ACK is returned with the rdr_errno field set to RDR_DATA_TIMEOUT. If this parameter is zero, this function is disabled. raduga2_message_length conveys the number of 30-bit words that comprise the Raduga-2 message. This value will be reflected in bits 13-15 of the first 30-bit word of the message. Valid length values are: 1, 2, and 5. raduga2_message_identifier conveys the identifier type of the message. This value will be reflected in bits 16 and 17 of the first 30-bit word of the message. Valid values are: 0, 1, 2, and 3.
89
State
New State
Response
Reasons for Failure

90
RDR_DATA_IND
RDR_DATA_IND
When radar messages are received on a connection, RDR uses this primitive to convey the messages to the application. RDR also sends this primitive on a periodic basis when the link is idle (no valid Radar Receiver messages are received) or non-operational (no valid idle characters are received). The non-operational state applies only to CD-2, Marconi, Modified Eurocontrol, General 18-Bit and NEC Radar Extractor. The circumstances under which RDR forwards a block of messages to the application is determined by configuration parameters included with the RDR_BIND_REQ. An RDR_DATA_IND primitive is sent to the application when the maximum number of messages is received or when the timeout period expires, whichever occurs first. (See A Note About Configuration on page 99 for details.) For any given serial link, RDR guarantees to deliver each radar message to the application in the same order as received on that serial link. If more than one DLSAP is bound to the connection, messages received on different serial links are not necessarily in chronological sequence within an RDR_DATA_IND.
Message Format
The control part of the message is defined by the following structure: typedef struct { bit32 rdr_primitive; bit32 rdr_reason; bit32 rdr_msg_count; } rdr_data_ind_t; See rdr_data_ind_t RMH Structure Parameters on page 94 for a description of each parameter. The data part of the message contains received radar messages, each of which is preceded by a radar message header (RMH) structure. The format of this structure is dependent on the radar data type, but the first field always specifies the serial link. The link number, which in turn identifies the radar type, can be used to determine the format of the remainder of the structure. In the general case, the RMH structure provides information related to a radar message, and is followed by the message itself. When no valid radar messages are received on a serial link within the configured timeout period, the RMH structure only signifies that no data was received, and is not followed by a radar message.
91
CD-2 (FPS 117), Marconi 10-Bit, Modified Eurocontrol, General 18-Bit and NEC Radar Extractor RMH Structure
For CD-2 (FPS 117), Marconi 10-Bit, Modified Eurocontrol, General 18-Bit and NEC Radar Extractor, the RMH structure is defined as follows: typedef struct { bit32 bit32 struct utimeval wanStrProt_timeStatus_t bit32 bit32 } cd_message;
cd_link; cd_time_stamp; cd_sntp_time_stamp; cd_timeStatus; cd_length; cd_idles;
See cd_message RMH Structure Parameters on page 95 for a description of each parameter.
ASTERIX RMH Structure

For ASTERIX, the RMH structure is defined as follows: typedef struct { bit32 bit32 struct utimeval wanStrProt_timeStatus_t bit32 bit32 } as_message;
as_link; as_time_stamp; as_sntp_time_stamp; as_timeStatus; as_length; as_reserved;
See as_message RMH Structure Parameters on page 95 for a description of each parameter.
Thompson-CSF, Thompson-TVT2 and Toshiba RMH Structure

For Thompson-CSF, Thompson-TVT2 and Toshiba, the RMH structure is defined as follows: typedef struct { bit32 bit32 struct utimeval wanStrProt_timeStatus_t bit32 bit8 bit8 bit16 } tc_message;
tc_link; tc_time_stamp; tc_sntp_time_stamp; tc_timeStatus; tc_length; tc_hdr1; tc_hdr2; tc_reserved;
See tc_message RMH Structure Parameters on page 96 for a description of each parameter.
92
RDR_DATA_IND
TPS-43 and TPS-75 RMH Structure

For TPS-43 and TPS-75, the RMH structure is defined as follows: typedef struct { bit32 bit32 struct utimeval wanStrProt_timeStatus_t bit32 bit32 } tp_message;
tp_link; tp_time_stamp; tp_sntp_time_stamp; tp_timeStatus; tp_length; tp_reserved;
See tp_message RMH Structure Parameters on page 97 for a description of each parameter.
Raduga-2 RMH Structure

For Raduga-2, the RMH structure is defined as follows: typedef struct { bit32 bit32 struct utimeval wanStrProt_timeStatus_t bit32 raduga2_info_t bit16 } raduga2_message;
raduga2_link; raduga2_time_stamp; raduga2_sntp_time_stamp; raduga2_timeStatus; raduga2_length; raduga2_info; raduga2_reserved;
See raduga2_message RMH Structure Parameters on page 98 for a description of each parameter.
Parameters
rdr_data_ind_t RMH Structure Parameters
In the rdr_data_ind_t structure: rdr_primitive rdr_reason conveys RDR_DATA_IND. indicates the reason for the RDR_DATA_IND, as follows: DL_TIMEDOUT The RDR timeout value was reached before the maximum number of radar messages was received. DL_BUFFULL The maximum number of radar messages was received before the timeout occurred. (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.
93
cd_message RMH Structure Parameters

In the cd_message RMH structure: cd_link cd_time_stamp identifies the serial link on which the message was received (and indirectly identifies the radar data format). contains the time stamp (tick count), recorded at the time the first byte of the message was received.
cd_sntp_time_stamp contains the optional SNTP timestamp applied to received message blocks. This field only applies to certain models of PTI LAN-based servers. The timestamp is reported in a structure that consists of two fields: the number of seconds and the number of microseconds of Universal Coordinated Time (UTC). cd_timeStatus specifies the external timestamp status if it is being used (see the parameter options1 of the appropriate Bind Request RDR_BIND_REQ on page 31). 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:
indicates that the external clocks internal oscillator is not accurate and could indicate a hardware problem. cd_length identifies the size of the received radar message, in bytes. If length is zero, no messages were received on the serial link within the configured timeout period. specifies the number of received idle characters that preceded the associated radar message (the number of idles since the previous message was received, or since synchronization was achieved). The value of idles is valid even if length is zero. If idles is zero, the serial link is not operating correctly.
cd_idles
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).
94
RDR_DATA_IND
as_time_stamp
contains the time stamp (tick count), recorded at the time the first byte of the message was received.
as_sntp_time_stamp contains the optional SNTP timestamp applied to received message blocks. This field only applies to certain models of PTI LAN-based servers. The timestamp is reported in a structure that consists of two fields: the number of seconds and the number of microseconds of Universal Coordinated Time (UTC). as_timeStatus specifies the external timestamp status if it is being used (see the parameter options1 of the appropriate Bind Request RDR_BIND_REQ on page 31). 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:
indicates that the external clocks internal oscillator is not accurate and could indicate a hardware problem. as_length identifies the size of the received radar message, in bytes. If length is zero, no messages were received on the serial link within the configured timeout period. is not used.
as_reserved
tc_message RMH Structure Parameters

In the tc_message RMH structure: tc_link tc_time_stamp identifies the serial link on which the message was received. contains the time stamp (tick count), recorded at the time the first byte of the message was received.
tc_sntp_time_stamp contains the optional SNTP timestamp applied to received message blocks. This field only applies to certain models of PTI LAN-based servers. The timestamp is reported in a structure that consists of two fields: the number of seconds and the number of microseconds of Universal Coordinated Time (UTC).
95
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 31). 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:
indicates that the external clocks internal oscillator is not accurate and could indicate a hardware problem. tc_length identifies the size of the data portion of either the Thompson-CSF radar message, the Thompson-TVT2 radar message or the Toshiba radar message, in bytes. If length is zero, no messages were received on the serial link within the configured timeout period. for either a Thompson-CSF or a Thompson-TVT2 radar message, contains the first byte of the two-byte header. For a Toshiba radar message, this field is not used. for either a Thompson-CSF or a Thompson-TVT2 radar message, contains the second byte of the two-byte header. For a Toshiba radar message, this field is not used. is not used.
tc_hdr1
tc_hdr2
tc_reserved
tp_message RMH Structure Parameters

In the tp_message RMH structure: tp_link tp_time_stamp identifies the serial link on which the message was received. contains the time stamp (tick count), recorded at the time the first byte of the message was received.
tp_sntp_time_stamp contains the optional SNTP timestamp applied to received message blocks. This field only applies to certain models of PTI LAN-based servers. The timestamp is reported in a structure that consists of two fields: the number of seconds and the number of microseconds of Universal Coordinated Time (UTC).
96
RDR_DATA_IND
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 31). 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. is not used.
tp_reserved
raduga2_message RMH Structure Parameters

In the raduga2_message RMH structure: raduga2_link identifies the serial link on which the message was received.
raduga2_time_stamp contains the time stamp (tick count), recorded at the time the first byte of the message was received. raduga2_sntp_time_stamp contains the optional SNTP timestamp applied to received message blocks. This field only applies to certain models of PTI LAN-based servers. The timestamp is reported in a structure that consists of two fields: the number of seconds and the number of microseconds of Universal Coordinated Time (UTC). raduga2_timeStatus specifies the external timestamp status if it is being used (see the parameter options1 of the appropriate Bind Request RDR_BIND_REQ on page 31). 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:
97
raduga2_length
identifies the size of the data portion of the Raduga-2 radar message, in bytes. If length is zero, no messages were received on the serial link within the configured timeout period. contains the Raduga-2 Message Length and Message Identifier values. is not used.
raduga2_info raduga2_reserved
A Note About Configuration

With each bind request (RDR_BIND_REQ), the application specifies a timeout value and maximum number of messages for the radar mux and a timeout value and maximum number of messages for the radar protocol module, see Table 4-3: Timeout and Messages Parameters. Table 4-3: Timeout and Messages Parameters Module
Radar Mux CD-2, Marconi ASTERIX Thompson-CSF Thompson-TVT2 Toshiba TPS-43 Modified Eurocontrol General 18-Bit NEC Radar Extractor TPS-75 Raduga-2
Structure
rdr_bind_req_t cd_bind_req_t as_bind_req_t tc_bind_req_t tc_bind_req_t tc_bind_req_t tp_bind_req_t cd_bind_req_t cd_bind_req_t cd_bind_req_t tp_bind_req_t raduga2_bind_req_t
Timeout Parameter
rdr_message_timeout cd_fwd_time as_fwd_time tc_fwd_time tc_fwd_time tc_fwd_time tp_fwd_time cd_fwd_time cd_fwd_time cd_fwd_time tp_fwd_time raduga2_fwd_time
Messages Parameter
rdr_max_messages cd_maxmesg_cnt as_framesize tc_maxmesg_cnt tc_maxmesg_cnt tc_maxmesg_cnt tp_maxmesg_cnt cd_maxmesg_cnt cd_maxmesg_cnt cd_maxmesg_cnt tp_maxmesg_cnt raduga2_maxmesg_cnt
Each timeout and counter pair operates independently, as follows:

If the length field (cd_length, as_length, tc_length, tp_length, raduga2_length) of the RMH structure is zero, the next RMH follows immediately. For CD-2, Marconi, Thompson-CSF, Thompson-TVT2, Toshiba, TPS-43, TPS-75, Modified Eurocontrol, General 18-Bit, NEC Radar Extractor and Raduga-2, if the length field is non-zero the RMH is followed by a fixed number of data bytes. This number depends on the maximum message size configured for the serial link. The size specified by this parameter is rounded up to a multiple of four to determine the fixed data length following the RMH structure. (The actual number of valid bytes within that data is determined by the cd_length, tc_length. tp_length or raduga2_length field of the RMH structure).
98
RDR_DATA_IND
When the radar mux has received its maximum number of radar messages (compiled from all lower streams bound to the connection), it sends an RDR_DATA_IND upstream to the application. When the radar Muxs timeout expires before the maximum number of messages has been received from the lower streams, it sends an RDR_DATA_IND upstream to the application containing the messages it has received. However, if no messages are received from the lower streams during the timeout period, the radar mux sends no indication to the application. Depending on the configured timeout periods, an RDR_DATA_IND may include one or more empty (RMH-structure-only) messages from any or all of the bound serial links.
Data Format
The data portion of the RDR_DATA_IND primitive consists of one or more RMH structures, each of which is followed by a variable number of data bytes. The rdr_msg_count field of the rdr_data_ind_t structure indicates the total number of RMH structures included in the data. The offset from one RMH structure to the next is determined as follows:
If the length field (cd_length, as_length, tc_length, or tp_length) of the RMH structure is zero, the next RMH follows immediately. For CD-2, Marconi, Thompson-CSF, Thompson-TVT2, Toshiba, TPS-43, TPS-75, Modified Eurocontrol, General 18-Bit, and NEC Radar Extractor, if the length field is non-zero the RMH is followed by a fixed number of data bytes. This number depends on the maximum message size configured for the serial link. The size specified by this parameter is rounded up to a multiple of four to determine the fixed data length following the RMH structure. (The actual number of valid bytes within that data is determined by the cd_length, tc_length or tp_length field of the RMH structure.) For ASTERIX, if cd_length is non-zero the RMH is followed by as_length bytes rounded up to a multiple of four. (The as_length field specifies the actual number of valid bytes in the message.)
Message Format
Within the message data following the RMH structure, the format of the radar message itself depends on the radar data type. For CD-2, Marconi, Modified Eurocontrol and General 18-Bit, the format additionally depends on the value of the cd_packmesg parameter included in the bind request. In the diagrams below, each word of radar data is shown as a string of alphabetic characters, with the most-significant bit of the word in upper case.
CD-2 (FPS 117) Configured for Packed Data

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

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

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

The number of valid data bytes is determined by the value of the cd_length field in the cd_message structure. The radar message is stored in the first cd_length bytes following the RMH. Each pair of bytes (16-bit word) contains a single Marconi 10-bit word in the low order bits, and the high-order six bits are set to zero. Byte 1
000000Aa
Byte 2
aaaaaaaa
Byte 3
000000Bb
Byte 4
bbbbbbbb ...
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.
100
RDR_DATA_IND
ASTERIX
The number of valid data bytes is determined by the value of the as_length field in the as_message structure. The radar message, which consists of byte-aligned eight-bit values, is stored in the first as_length bytes following the RMH. Byte 1
Aaaaaaaa
Byte 2
Bbbbbbbb
Byte 3
Cccccccc
Byte 4
Dddddddd ...
Thompson-CSF, Thompson-TVT2 and Toshiba

Each of the Thompson-CSF, Thompson-TVT2 and Toshiba radar messages consists of a twobyte header and a variable number of data bytes. The header bytes are stored in the tc_hdr1 and tc_hdr2 fields of the tc_message structure. The number of valid data bytes is determined by the value of the tc_length field. The radar message is stored in the first tc_length bytes following the RMH, and consists of byte-aligned eight-bit values. Byte 1
Aaaaaaaa
Byte 2
Bbbbbbbb
Byte 3
Cccccccc
Byte 4
Dddddddd ...
TPS-43
Each of the TPS-43 radar messages consists of fourteen data groups. The message format of a received TPS-43 variant radar message is as follows, except for Enhanced TPS43_C, which is described below. The sync character(s) and the parity byte have been stripped out, except for non-enhanced TPS43_C. The number of valid data bytes is determined by the value of the tp_length field, which should be 14. The radar message is stored in the first tp_length bytes following the RMH, and consists of byte-aligned eight-bit values. Mark bits (if applicable) are not stripped out. For Enhanced TPS43_C, the sync character, mark bits, and the parity byte have been stripped out. The final mark bit is included with the data. The number of valid data bytes is determined by the value of the tp_length field, which is 13. The radar message is stored in the first tp_length bytes following the RMH. Since an Enhanced TPS43_C message is 98 bits and does not land on an 8 bit boundary, byte 13 is padded with zeros after the two data bits.
101
Modified Eurocontrol and General 18-Bit Configured for Packed Data

The number of valid data bytes is determined by the value of the cd_length field in the cd_message structure. The radar message is stored in the first cd_length bytes following the RMH, formatted as a continuous bit stream. (For example, the first three bytes contain the first 18-bit word and the most-significant six bits of the second word.) Depending on the message length, the last valid byte of the message may contain up to seven unused bits (in the low-order portion of the byte). Byte 1
Aaaaaaaa
Byte 2
aaaaaaaa
Byte 3
aaBbbbbb
Byte 4
bbbbbbbb
Byte5
bbbbCccc ...
Modified Eurocontrol and General 18-Bit Configured for Unpacked Data

The number of valid data bytes is determined by the value of the cd_length field in the cd_message structure. The radar message is stored in the first cd_length bytes following the RMH. Each sequence of four bytes (32-bit long word) contains a single General 18-Bit Modified Eurocontrol or 18-bit word in the low order bits, and the high-order 14 bits are set to zero. Byte 1
00000000
Byte 2
000000Aa
Byte 3
aaaaaaaa
Byte 4
aaaaaaaa
Byte 5
00000000
Byte 6
000000Bb
Byte 7
bbbbbbbb
Byte 8
bbbbbbbb ...
TPS-75
Each of the TPS-75 radar messages consists of fourteen data bytes. The sync character, mark bits, and the parity byte have been stripped out. The number of valid data bytes is determined by the value of the tp_length field, which should be 14. The radar message is stored in the first tp_length bytes following the RMH, and consists of byte-aligned eight-bit values. Byte 1
Aaaaaaaa
Byte 2
Bbbbbbbb
Byte 3
Cccccccc
Byte 4
Dddddddd ...
102
RDR_DATA_IND
Raduga-2
Each Raduga-2 message consists of 2 to 13 bytes of actual data payload. The barker code, parity bit, mark bits and control patterns have all been stripped out. Also, all Silence Messages are discarded. The radar message is stored in the first raduga2_length bytes following the RMH, and consists of byte-aligned eight-bit values. Byte 1
Aaaaaaaa
Byte 2
Bbbbbbbb
Byte 3
Cccccccc
Byte 4
Dddddddd ...
Example
Figure 4-1, Sample Message Formats, on page 105 shows two sample RDR_DATA_IND primitives containing radar messages received on four serial links, numbered 0 through 3. Table 4-4: Sample Message Format Configuration shows the configuration for the links in this example: Table 4-4: Sample Message Format Configuration Link
0 1 2 3
Radar Type
CD-2 ASTERIX Thompson-CSF Marconi 10-Bit
cd_packmesg
1 n/a n/a 0
Max Message Size

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

Message 1
RDR_DATA_IND DL_TIMEDOUT rdr_mesg_cnt = 4
Message 2 Control Part

RDR_DATA_IND DL_TIMEDOUT rdr_mesg_cnt = 3
cd_link = 0 cd_time_stamp cd_sntp_time_stamp cd_length = 9 cd_idles CD-2 Message

unused
Data Part
cd_link = 3 cd_time_stamp cd_sntp_time_stamp cd_length = 14 cd_idles

Marconi Message
cd_link = 0 cd_time_stamp cd_sntp_time_stamp cd_length = 12 cd_idles CD-2 Message cd_link = 3 cd_time_stamp cd_sntp_time_stamp cd_length = 0 cd_idles tc_link = 2 tc_time_stamp tc_sntp_time_stamp tc_length = 18 header reserved
unused
as_link = 1 as_time_stamp as_sntp_time_stamp as_length = 22 as_reserved ASTERIX Message

unused
tc_link = 2 tc_time_stamp tc_sntp_time_stamp tc_length = 12 header reserved
Thompson-CSF Message Data
Thompson-CSF Message Data unused
unused
The fourth RMH is followed by the 18-byte data part of a Thompson-CSF message from link 2. Since the link is configured for a maximum message size of 28, the 18 bytes of the message are followed by 10 unused bytes. The data part of the second RDR_DATA_IND contains three RMH structures. The first, from link 3, is followed by a 14-byte Marconi message. Link 3 is configured for unpacked data and a maximum message size of 24. Therefore, the message contains 7 10-bit words, contained in the low order 10 bits of each of the first 7 16-bit words; and there are 10 unused bytes before the next RMH. The second RMH is followed by a 22-byte ASTERIX message from link 1. For ASTERIX, the message size is rounded up to a four-byte boundary to determine the start of the next RMH. In this case, this results in 2 unused bytes before the final RMH.
104
RDR_DATA_IND
The third and last RMH, from link 2, is followed by the 12-bytes of data from a Thompson-CSF message, followed by 16 unused bytes.
State
New State
105
106
Chapter
5
Sample Test Programs
Overview
As examples of the interface to RDR, three test programs are included in source form release. They are called rdrcv, rdrxmt and rdrtest, and are located in the Radar Client directory. The test programs accept a number of command-line parameters for configuration of the general test environment, and interactively prompt for information regarding each serial link to be tested. The information requested includes link number, radar data format, configuration parameters for the bind, and filenames. Topics included in this chapter include:
Test Parameters on page 108 Run the Transmit and Receive Test Programs on page 109 Run the Full Duplex Radar Test Program on page 113
Receive Test Program

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

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

The rdrtest program demonstrates how to open and use a serial link for both reading and writing (READWRITE). This program has a conditional compile statement in it which will allow it to run with and without the radar daemon being present. Look for NO_DAEMON in the file rdrtest.c. Only QUICC based platforms (e.g. MPS300/600, Sbus 334, PCI/CPC 334) can be configured for reading and writing on the same port. Other platforms will return an error if the bind request has READWRITE specified for the connection type.
Test Parameters
The command lines for the three test programs are defined as follows:
rdrcv [-b baud] [-c controller] [-i] [-m maxcount] [-s server] [-t timeout] [-v service] [-P physical IF] rdrxmt [-b baud] [-c controller] [-i] [-s server] [-v service] [-P physical IF] rdrtest [-b baud] [-c controller] [-f framesize] [-l linkno] [-p proto] [-r rcvfile] [-s server] [-v service] [-x xmtfile] [-P physical IF]
-b baud
This parameter specifies the baud rate for the serial port. For external clocking (clock signal supplied by a modem or other external device), baud should be set to -1. External clocking is the default for rdrcv and rdrxmt; 9600 bps is the default for rdrtest. This parameter specifies the controller number. If not specified, controller defaults to 0. This parameter is used to specify the maximum frame size for the link. It will be rounded up to the nearest 4 byte boundary. The default is 512 bytes. This parameter specifies handling of input modem signals. If this option is not specified, a value of 0 (RDR_NO SIGS) is set and changes in modem signals are ignored by the driver. If this option is specified, a value of 1 (RDR_SIGS) is set and the application is notified upon a modem signals state change. This parameter identifies the serial link that will be associated with the connection. If not specified, the link defaults to 0. 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. 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. This parameter specifies the name of the file to receive. This is a required parameter.
-c controller -f framesize
-i
-l linkno -m maxcount
-p proto
-r rcvfile
108
Run the Transmit and Receive Test Programs
-s server
This parameter identifies the target server. For a LAN-based server, this is the logical host name as specified in the client's hosts database. For a controller installed in a backplane, server is the pathname of the driver's cloneable special file. If this option is not specified, the server name defaults to /dev/ucsclone for UNIX, and \\.\PTIXpqcc for Windows NT. Enable data acknowledgements. The number specified is the number of messages the client will send to the protocol before waiting to receive a data acknowledgement back from the protocol. 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). 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. This parameter specifies the name of the file to transmit. This is a required parameter. Specifies the physical interface for a CPC358. If this parameter is not specified, a value of 2 is used specifying an RS530 physical interface. See the parameter phyIf in the TADILB_BIND_REQ primitive for details on other options, RDR_BIND_REQ on page 31. This parameter is not applicable to any other controller.
-T
-t timeout
-v service
-x xmtfile -P physical IF

To run the test programs, you must connect a loopback cable between two serial ports. You will specify one of the two links when prompted by rdrcv and the other when prompted by rdrxmt. If you have a LAN-based server, power it on and wait for it to download. If you have an embedded server, load it using the commload utility. (Download procedures are described in the MPS Software and Hardware Install Guide.) Start rdrcv first. The example shown below uses the default server name, controller number and baud rate, but sets the maximum message count to 40 and the timeout value to 50 (5 seconds).
rdrcv -m 40 -t 50
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.)
109
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 3) thompcsf 4) euro 5) gen18 6) toshiba 7) tps43 8) nec 9) tps75 10) raduga2
110
protocol [0]: Framesize [256]: Timeout baud [9600]: Reply timeout [30]: Pack messages (0 = no, 1 = yes) [0]: Invert data (0 = no, 1 = yes) [0]: Name of receive file: rcv0 link number (-1 to continue) [-1]: 2 0) cd2 1) marconi10 2) asterix 3) thompcsf 4) euro 5) gen18 6) toshiba 7) tps43 8) nec 9) tps75 10) raduga2 protocol [0]: 3 Framesize [256]: 128 Timeout baud [9600]: Reply timeout [30]: Name of receive file: rcv2 link number (-1 to continue) [-1]: 4 0) cd2 1) marconi10 2) asterix 3) thompcsf 4) euro 5) gen18 6) toshiba 7) tps43 8) nec 9) tps75 10) raduga2 protocol [0]: 1 Framesize [256]: 128 Timeout baud [9600]: 4800 Reply timeout [30]: 40 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
111
3) thompcsf 4) euro 5) gen18 6) toshiba 7) tps43 8) nec 9) tps75 10) radagu2 protocol [0]: 2 Framesize [256]: 512 Timeout baud [9600]: 2400 Reply timeout [30]: 40 Which data encoding method for ASTERIX? -------------------------------------------0) NRZ 1) NRZI 2) FM0 for RAMP Radar 3) FM1 4) Manchester 5) Differential Manchester Choice [0]: 0 Name of receive file: rcv6 link number (-1 to continue) [-1]: Sending Open Server Request. M E N U P Print A Dot For Each Block Received S Print rdrcv Statistics At Periodic Intervals Option [P]:
rdrxmt Example
A sample execution of rdrxmt is shown below, demonstrating responses to its interactive prompts.
$ rdrxmt -b 4800 -s radarbox LINK CONFIGURATION link number [1]: 0) cd2 1) marconi10 2) asterix 3) thompcsf 4) euro 5) gen18 6) toshiba 7) tps43 8) nec 9) tps75 10) raduga2
112
Run the Full Duplex Radar Test Program
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 .........................................................

To run the read/write radar test program, you must connect a loopback cable between two serial links. Two copies of rdrtest should be run; each reading and writing from the links that are connected to each other. If you have a LAN-based server, power it on and wait for it to download. If you have an embedded server, load it using the commload utility. (Download procedures are described in the MPS Software and Hardware Install Guide.) Start the two rdrtest programs in separate windows with the same protocol specified. The example shown below will configure link 0 for the Toshiba protocol. It will transmit the Makefile, and receive any data coming into the link to the file called foo. This will use the default values for the server name, controller number, baud rate and frame size.
rdrtest -p toshiba -l 0 -x rdrtest.c -r foo1 rdrtest -p toshiba -l 1 -x rdrtest.c -r foo2
rdrtest will prompt you for link configuration information. Once all the link configuration parameters have been specified, the radar test program will open to the radar multiplexor (rdrmux). If the program was compiled to not use the Radar Daemon, it will then open to the specified protocol (in this case Toshiba), link it under the radar multiplexor, and attach it to the physical link. Next the program will bind the link with the desired configuration parameters. At this point, the program is ready to transmit and receive data. 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.
113
$ rdrtest -b 19200 -f 256 -p thompcsf -l 0 -x rdrtest.c -r foo rdrtest link parameters: -----------------------Link: 0 Baud Rate: 19200 Frame Size: 256 Server: /dev/ucsclone Service: mps Controller: 0 Protocol: thompcsf Transmit File: rdrtest Receive File: foo
Which variant of Thompson? ---------------------------0) TCSF 1) TVT2 Choice [0]: Open Radar Mux. Open to protocol thompcsf Link protocol to rdrmux Close protocol stream. Sending ATTACH Sending Bind request link 0 Received RDR_BIND_ACK Received RDR_OK_ACK to RDR_CLEAR_TICK Ready ????? rxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrx rxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrx rxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrxrx rxrxrxrxrxrxrxxxxxxxxrxrxrxxxxxxxrxrxrxrxrxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxrxrxrxrxrxrxrxrxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr rrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr rrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr rrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr rrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrNull message received on link 0 rNull message received on link 0 rNull message received on link 0 rNull message received on link 0 ^Cr **** Protocol Statistics **** Link 0 (thompcsf) recv_msgs: 483
114
xmit_msgs: recv_2big: xmit_2big: recv_orun: no_timers: no_buffers: bad_bcc: bad_mtype: no_clocks:
483 0 0 0 0 0 0 0 0
Sending Unbind request link 1 Received RDR_OK_ACK to RDR_UNBIND_REQ Detach link request Unlink protocol module from stream End rdrtest test program.
115
116
Index
A
Application Programming Interface (API) . . . . . . . . . . . . .18 as_bind_req_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32 AS_DATA_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55, 82 as_data_req_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .82 as_message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .93 AS_STATISTICS_ACK . . . . . . . . . . . . . . . . . . . . . . . . 64, 65 AS_STATISTICS_REQ . . . . . . . . . . . . . . . . . . . . . . . . 64, 65 as_statistics_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .65 ASTERIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .102 Data Part (as_bind_req_t) . . . . . . . . . . . . . . . . . . . . . . . .32 RDR Primitive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26 RMH Stucture (as_message) . . . . . . . . . . . . . . . . . . . . .93
Configuration File Format . . . . . . . . . . . . . . . . . . . . . . . . . 22 Configured for Packed Data CD-2 (FPS 117) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . General 18-Bit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Marconi 10-Bit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Modified Eurocontrol . . . . . . . . . . . . . . . . . . . . . . . . . . Configured for Unpacked Data CD-2 (FPS 117) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . General 18-Bit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Marconi 10-Bit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Modified Eurocontrol . . . . . . . . . . . . . . . . . . . . . . . . . .
100 103 101 103
101 103 101 103
Customer Support and Services . . . . . . . . . . . . . . . . . . . 14
D
Data Format (CD_DATA_REQ) CD-2 (FPS 117) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . General 18-Bit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Marconi 10-Bit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Modified Eurocontrol . . . . . . . . . . . . . . . . . . . . . . . . . . . NEC Radar Extractor . . . . . . . . . . . . . . . . . . . . . . . . . . .
77 79 78 79 80
C
cd_bind_req_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32 CD_DATA_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . 39, 55, 77 cd_message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .93 CD_STATISTICS_ACK . . . . . . . . . . . . . . . . . . . . . . . . 61, 62 CD_STATISTICS_REQ . . . . . . . . . . . . . . . . . . . . . . . . 61, 62 cd_statistics_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62, 63 CD-2 (FPS 117) Configured for Packed Data . . . . . . . . . . . . . . . . . . .100 Configured for Unpacked Data . . . . . . . . . . . . . . . . .101 Data Format (CD_DATA_REQ) . . . . . . . . . . . . . . . . . . .77 Data Part (cd_bind_req_t) . . . . . . . . . . . . . . . . . . . . . . . .31 RDR Primitive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26 RMH Structure (cd_message) . . . . . . . . . . . . . . . . . . . .93 commload utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . .109, 113
Data Format (TC_DATA_REQ) Thompson-CSF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 Thompson-TVT2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 Toshiba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 Data Link Provider Interface (DLPI) . . . . . . . . . . . . . . . . . 17 Data Link Service Access Points (DLSAPs) . . . . . . . . . 19 Data Part (as_bind_req_t) ASTERIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Data Part (cd_bind_req_t) CD-2 (FPS 117) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . General 18-Bit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Marconi 10-Bit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Modified Eurocontrol . . . . . . . . . . . . . . . . . . . . . . . . . . . NEC Radar Extractor . . . . . . . . . . . . . . . . . . . . . . . . . . .
31 31 31 31 31
117
Index
Data Part (raduga2_bind_req_t) Raduga-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34 Data Part (tc_bind_req_t) . . . . . . . . . . . . . . . . . . . . . . . . . .33 Thompson-CSF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33 Thompson-TVT2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33 Data Part (tp_bind_req_t) TPS-43 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33 TPS-75 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33 DL_BUFFULL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .94 DL_TIMEDOUT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .94 DLPI (Data Link Provider Interface) . . . . . . . . . . . . . . . . . . . .17 Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25 Services Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19 DLSAP (Data Link Service Access Points) . . . . . . . . . . .19
MPSgetmsg . . . . . . . . . . . . . . . . . . . . . . . . . . 18, 26, 110, 113 MPSioctl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18, 19, 28 MPSopen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18, 19, 110 MPSpoll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 MPSputmsg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18, 26, 110
N
NEC Radar Extractor . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 Data Format (CD_DATA_REQ) . . . . . . . . . . . . . . . . . . 80 Data Part (cd_bind_req_t) . . . . . . . . . . . . . . . . . . . . . . . 31 RDR Primitive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 RMH Stucture (cd_message) . . . . . . . . . . . . . . . . . . . . 93
P
Primitive That Provides Statistics . . . . . . . . . . . . . . . . . . . 27 Primitive Used to Request Statistics . . . . . . . . . . . . . . . . 27 Primitives Used Request Statistics About a Serial Link . . . . . . . . . . . . 27 Transmit Radar Data on a Serial Link . . . . . . . . . . . . . 26 Product Warranty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
E
EACCESS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81, 86, 89, 91 ENOLINK . . . . . . . . . . . . . . . . . . . . . . . . . . . 81, 83, 86, 89, 91
F
Full Duplex Radar Test Program (rdrtest) . . . . . . .108, 113
R
Radar Daemon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Radar Data Format . . . . . . . . . . . . . . . . . . . . . . . . . 17, 22, 26 Radar Receiver Protocols . . . . . . . . . . . . . . . . . . . . . . . . . 25 Radar Receiver System Configuration . . . . . . . . . . . . . . 20 Raduga-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 Data Part (raduga2_bind_req_t) . . . . . . . . . . . . . . . . . 34 RDR Primitive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 RMH Stucture (raduga2_message) . . . . . . . . . . . . . . . 94 raduga2_bind_req_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 RADUGA2_DATA_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . 90 raduga2_data_req_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 raduga2_message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 RADUGA2_STATISTICS_ACK . . . . . . . . . . . . . . . . . 73, 74 RADUGA2_STATISTICS_REQ . . . . . . . . . . . . . . . . . 73, 74 raduga2_statistics_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 RDR Primitive ASTERIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CD-2 (FPS 117) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . General 18-Bit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Marconi 10-Bit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Modified Eurocontrol . . . . . . . . . . . . . . . . . . . . . . . . . . . NEC Radar Extractor . . . . . . . . . . . . . . . . . . . . . . . . . . .
26 26 26 26 26 26
G
General 18-Bit Configured for Packed Data . . . . . . . . . . . . . . . . . . .103 Configured for Unpacked Data . . . . . . . . . . . . . . . . .103 Data Format (CD_DATA_REQ) . . . . . . . . . . . . . . . . . . .79 Data Part (cd_bind_req_t) . . . . . . . . . . . . . . . . . . . . . . . .31 RDR Primitive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26 RMH Structure (cd_message) . . . . . . . . . . . . . . . . . . . .93
M
Marconi 10-Bit Configured for Packed Data . . . . . . . . . . . . . . . . . . .101 Configured for Unpacked Data . . . . . . . . . . . . . . . . .101 Data Format (CD_DATA_REQ) . . . . . . . . . . . . . . . . . . .78 Data Part (cd_bind_req_t) . . . . . . . . . . . . . . . . . . . . . . . .31 RDR Primitive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26 RMH Structure (cd_message) . . . . . . . . . . . . . . . . . . . .93 Modified Eurocontrol Configured for Packed Data . . . . . . . . . . . . . . . . . . .103 Configured for Unpacked Data . . . . . . . . . . . . . . . . .103 Data Format (CD_DATA_REQ) . . . . . . . . . . . . . . . . . . .79 Data Part (cd_bind_req_t) . . . . . . . . . . . . . . . . . . . . . . . .31 RDR Primitive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26 RMH Structure (cd_message) . . . . . . . . . . . . . . . . . . . .93 MPSclose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19
118
Index
Raduga-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27 Thompson-CSF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26 Thompson-TVT2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26 Toshiba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26 TPS-43 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26 TPS-75 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27 RDR_ATTACH_PENDING . . . . . . . . . . . . . . . . . . . . . . . . .29 RDR_ATTACH_REQ . . . . . . . . . . . . . . . . . . . . 22, 28, 30, 53 rdr_attach_req_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28 RDR_ATTACHED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29 RDR_BAD_CRC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46 RDR_BAD_DATA_BLOCK . . . . . . . . . . . . . . . 81, 86, 89, 91 RDR_BAD_DATA_FORMAT . . . . . . . . . . . . . 81, 86, 89, 91 RDR_BAD_MARKBIT . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46 RDR_BIND_ACK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50, 51 rdr_bind_ack_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .51 RDR_BIND_PENDING . . . . . . . . . . . . . . . . . . . . . . . . 50, 51 RDR_BIND_REQ . . . . . . . . . . . . . . 31, 35, 36, 51, 52, 92, 99 rdr_bind_req_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31 RDR_CLEAR_TICK . . . . . . . . . . . . . . . . . . . . . . . . . . . 53, 60 RDR_DATA_ACK . 54, 77, 81, 82, 83, 85, 86, 88, 89, 90, 91 rdr_data_ack_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .54 RDR_DATA_IND . . . . . . . . . 36, 37, 38, 48, 92, 94, 100, 104 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .104 rdr_data_ind_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .92 RDR_DATA_TIMEDOUT . . . . . . . . . . . . . 81, 83, 86, 89, 91 RDR_DATA_TIMEOUT . . . . . . . . . . . . . . . 77, 82, 85, 88, 90 RDR_DATAXFER 30, 50, 51, 52, 59, 61, 63, 64, 66, 67, 70, 73, . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81, 82, 85, 88, 91, 106 RDR_DETACH_PENDING . . . . . . . . . . . . . . . . . . . . . . . . .30 RDR_DETACH_REQ . . . . . . . . . . . . . . . . . . . . . . 28, 30, 53 RDR_DLSAP_IN_USE . . . . . . . . . . . . . . . . . . . . . . . . . . . .50 RDR_EROR_IND . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44 RDR_ERROR_ACK 29, 30, 50, 52, 56, 60, 61, 64, 67, 70, 73, . . . . . . . . . . . . . . . . . . 77, 81, 82, 83, 85, 86, 88, 89, 90, 91 rdr_error_ack_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56 RDR_ERROR_IND . . . . . . . . . . . . . . . . . . . . . 39, 46, 48, 58 rdr_error_ind_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .58 RDR_INVALID_BIND_PARAMS . . . . . . . . . . . . . . . . . . . .50 RDR_INVALIDPORT . . . . . . . . . . . . . . 30, 50, 52, 60, 61, 64 RDR_LINKDOWN . . . . . . . . . . . . . . . . . . . . . . 39, 44, 46, 48
RDR_LINKUP . . . . . . . . . . . . . . . . . . . . . . . . . . 39, 44, 46, 48 RDR_NO_SIGS . . . . . . . . . . . . . . . . . . . . . . . . . 39, 43, 46, 48 RDR_NOFREEUSCB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 RDR_NOSUCHPROTOCOL . . . . . . . . . . . . . . . . . . . 29, 50 RDR_NOTATTACHED . . . . . . . . . . . . . . . . . . . . . . . . 29, 30 RDR_NOTAUTHOR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 RDR_NOTINIT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 RDR_OK_ACK . . . . . . . . . . . . . . . . . . . . . . 29, 30, 52, 53, 60 rdr_ok_ack_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 rdr_primitive 30, 52, 60, 61, 62, 64, 65, 67, 68, 70, 71, 73, 74, 77 RDR_READONLY . . . . . . . . . . . . . . . . . . . . . . 38, 43, 46, 48 RDR_READWRITE . . . . . . . . . . . . . . . . . . 38, 43, 46, 48, 90 RDR_SIGS . . . . . . . . . . . . . . . . . . . . . . . 39, 44, 46, 48, 49, 59 RDR_UNBIND_PENDING . . . . . . . . . . . . . . . . . . . . . . . . 52 RDR_UNBIND_REQ . . . . . . . . . . . . . . . . . . . . . . . 31, 52, 53 RDR_UNBOUND . . . . . . . . . . . . . . . . . . . . . . . 29, 30, 50, 52 RDR_WRITEONLY . . . . . . . . . . . . . . . . . . . 38, 43, 46, 48, 90 rdrconfig . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 rdrcv Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 rdrcv Test Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 rdrd Radar Daemon . . . . . . . . . . . . . . . . . . . . . . . . . . . 21, 23 rdrmux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18, 19, 110, 113 rdrtest Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 rdrtest Test Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 rdrxmt Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 rdrxmt Test Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 Receive Test Program (rdrcv) . . . . . . . . . . . . . . . . . 107, 109 RMH Structure ASTERIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CD-2 (FPS 117) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . General 18-Bit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Marconi 10-Bit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Modified Eurocontrol . . . . . . . . . . . . . . . . . . . . . . . . . . . NEC Radar Extractor . . . . . . . . . . . . . . . . . . . . . . . . . . . Raduga-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Thompson-CSF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Thompson-TVT2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Toshiba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . TPS-43 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . TPS-75 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
93 93 93 93 93 93 94 93 93 93 94 94
119
Index
T
tc_bind_req_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33 TC_DATA_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . 55, 84, 85 tc_data_req_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .85 tc_message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .93 TC_STATISTICS_ACK . . . . . . . . . . . . . . . . . . . . . . . . 67, 68 TC_STATISTICS_REQ . . . . . . . . . . . . . . . . . . . . . . . . 67, 68 tc_statistics_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .68 Test Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .107 Text Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14 Thompson-CSF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .102 Data Format (TC_DATA_REQ) . . . . . . . . . . . . . . . . . . .84 Data Part (tc_bind_req_t) . . . . . . . . . . . . . . . . . . . . . . . .33 RDR Primitive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26 RMH Structure (tc_message) . . . . . . . . . . . . . . . . . . . . .93 Thompson-TVT2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .102 Data Format (TC_DATA_REQ) . . . . . . . . . . . . . . . . . . .84 Data Part (tc_bind_req_t) . . . . . . . . . . . . . . . . . . . . . . . .33 RDR Primitive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26 RMH Structure (tc_message) . . . . . . . . . . . . . . . . . . . . .93 Timeout and Messages Parameters . . . . . . . . . . . . . . . . .99 Toshiba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .102 Data Format (TC_DATA_REQ) . . . . . . . . . . . . . . . . . . .84 Data Part (tc_bind_req_t) . . . . . . . . . . . . . . . . . . . . . . . .33 RDR Primitive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26 RMH Stucture (tc_message) . . . . . . . . . . . . . . . . . . . . .93 tp_bind_req_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34 TP_DATA_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . 55, 87, 88 tp_data_req_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .88 tp_message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .94 TP_STATISTICS_ACK . . . . . . . . . . . . . . . . . . . . . . . . 70, 71 TP_STATISTICS_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . .70 tp_statistics_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .71 TPS-43 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .102 Data Part (tp_bind_req_t) . . . . . . . . . . . . . . . . . . . . . . . .33 RDR Primitive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26 RMH Structure (tp_message) . . . . . . . . . . . . . . . . . . . .94 TPS43_A variant radar message . . . . . . . . . . . . . . . . . . .87 TPS43_B variant radar message . . . . . . . . . . . . . . . . . . .87 TPS43_C variant radar message . . . . . . . . . . . . . . . . . . .87 TPS43_C, Enhanced, radar message . . . . . . . . . . . . . . .87 TPS43_D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .87 TPS-75 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .103 120
Data Part (tp_bind_req_t) . . . . . . . . . . . . . . . . . . . . . . . radar message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . RDR Primitive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . RMH Stucture (tp_message) . . . . . . . . . . . . . . . . . . . .
33 88 27 94
Transmit Test Program (rdrxmt) . . . . . . . . . . . . . . . 107, 109
V
Valid Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
W
wanStrC_serRxTxEncode_t . . . . . . . . . . . . . . 40, 44, 47, 50
X
X_LINK, MPSioctl call . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Radar Receiver Manual

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Radar Receiver Manual

Uploaded by

Copyright:

Available Formats

Radar Receiver User Guide

2007 Performance Technologies, Inc. All Rights Reserved.

Document Revision History Part Number

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

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

Chapter 1: About This Guide

Chapter 2: Introduction to Radar Receiver

Chapter 3: Radar Daemon Process

Chapter 4: Control Primitives

Chapter 5: Sample Test Programs

Chapter 1: About This Guide

What it is Used For

<> Regular font

Customer Support and Services

include your return email address, and a telephone number.

Chapter 1: About This Guide

Radar Data Formats

Chapter 2: Introduction to Radar Receiver

General 18 Bit NEC Radar Extractor TPS-75 Raduga-2

Application Programming Interface

Overview of DLPI Services

Overview of DLPI Services

Chapter 2: Introduction to Radar Receiver

Figure 2-1: Radar Receiver System Configuration

Chapter 3: Radar Daemon Process

Configuration File Format

Table 3-1: Valid Protocols Radar Data Format

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

Running the Radar Daemon

link protocol link protocol link protocol link protocol

0 marconi10 1 asterix 2 asterix 3 cd2

Running the Radar Daemon

Chapter 3: Radar Daemon Process

Chapter 4: Control Primitives

RDR Primitive Used

Primitive Used to Request Statistics

Primitive That Provides Statistics

Chapter 4: Control Primitives

CD-2 or FPS 117 Marconi 10-Bit ASTERIX Thompson-CSF

thompcsf toshiba tps43 euro gen18 nec tps75 raduga2

Reasons for Failure

Chapter 4: Control Primitives

Reasons for Failure

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

Chapter 4: Control Primitives

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

ASTERIX Data Part

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

Thompson-CSF, Thompson-TVT2 and Toshiba Data Part

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

TPS-43 and TPS-75 Data Part

Chapter 4: Control Primitives

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

Raduga-2 Data Part

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

Chapter 4: Control Primitives

euro gen18 nec tps75 raduga2 rdr_max_messages

Modified Eurocontrol General 18-Bit NEC Radar Extractor TPS-75 Raduga-2

cd_bind_req_t Structure Parameters

Chapter 4: Control Primitives

Chapter 4: Control Primitives

as_bind_req_t Structure Parameters

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