Agilent 8712ES Programmer’s Guide

Download

Programmer’s Guide

HP 8712ET/ES and HP 8714ET/ES

RF Network Analyzers

HP Part No. 08714-90015

Printed in USA

Print Date: October 1999

Supersedes: October 1998

Notice

Softkey

The information contained in this document is subject to change without notice.

Hewlett-Packard makes no warranty of any kind with regard to this material, including but not limited to, the implied warranties of merchantability and ﬁtness for a particular purpose. Hewlett-Packard shall not be liable for errors contained herein or for incidental or consequential damages in connection with the furnishing, performance, or use of this material.

Key Conventions

This manual uses the following conventions:

FRONT PANEL KEY

analyzer (a “hardkey”).

: This indicates a “softkey”-- a key whose label is determined by the instrument’s ﬁrmware, and is displayed on the right side of the instrument’s screen next to the eight unlabeled keys.

: This represents a key physically located on the

Firmware Revision

This manual documents analyzers with ﬁrmware revisions E.06.00 and above.

ii Programmer’ s Guide

HP-IB Programming

This document is an introduction to programming your analyzer over the Hewlett-Packard Interface Bus (HP-IB). Its purpose is to provide concise information about the operation of the instrument under HP-IB control. It provides some background information on the HP-IB and some short programming examples to demonstrate the remote operation of the analyzer.

Example programs can be run on the analyzer’s internal controller or on an external controller. These programs can be found in the following three locations:

• Example Programs Disk (included with the analyzer)— DOS Format : part number 08714-10003.

A LIF version of the Example Programs Disk is available, but is not shipped with your analyzer:

ExamplePrograms Disk – LIF Format HP part number 08714-10004. Contact the nearest HP sales ofﬁce for ordering information. A list of

HP sales and service ofﬁces can be found in the “Speciﬁcations” chapter of the User’s Guide.

• Example Programs Guide (included with the analyzer): part number 08714-90016. (This document may not include all of the example programs found on the disk or on the Web site.)

• Web site http://www.hp.com or http://www.agilent.com. Use the search function to ﬁnd Web pages related to 8712 example programs.

You should become familiar with the operation of your network analyzer before controlling it over HP-IB. This document is not intended to teach programming or to discuss HP-IB theory except at an introductory level. Related information can be found in the following references:

• Information on making measurements with the analyzer is available in the analyzer’s User’s Guide.

• Information on HP Instrument BASIC is available in the HP Instrument BASIC User’s Handbook.

Programmer’s Guide iii

• Information on HP BASIC programming is available in the manual set for the BASIC revision being used. For example: BASIC 7.0 Programming Techniques and BASIC 7.0 Language Reference.

• Example programs are described in Example Programs Guide.

• Information on using the HP-IB is available in the Tutorial Description of the Hewlett-Packard Interface Bus (HP literature no. 5021-1927).

• Information on using the analyzer to make automated measurements is available in Automated Measurements User’s Guide Supplement.

• Information on using the analyzer with a Local Area Network (LAN) is available in The LAN Interface User’s Guide.

Contact the nearest HP sales ofﬁce for ordering information. A list of HP sales and service ofﬁces can be found in the “Speciﬁcations” chapter of the User’s Guide.

iv Programmer’ s Guide

HP 8712ET/ES and HP 8714ET/ES Network Analyzer Documentation Map

The CDROM provides the contents of all of the documents listed below.

The User’s Guide shows how to make measurements, explains commonly-used features, and tells you how to get the most performance from the analyzer.

The LAN Interface User’s Guide Supplement shows how to use a local area network (LAN) for programming and remote operation of the analyzer.

The Automating Measurements User’s Guide Supplement provides information on how to conﬁgure and control test systems for automation of test processes.

The Programmer’s Guide provides programming information including HP-IB and SCPI command references, as well as short programming examples.

Programmer’s Guide v

The Example Programs Guide provides a tutorial introduction using BASIC programming examples to demonstrate the remote operation of the analyzer

The Service Guide provides the information needed to adjust, troubleshoot, repair, and verify analyzer conformance to published speciﬁcations.

The HP Instrument BASIC User’s Handbook describes programming and interfacing techniques using HP Instrument BASIC, and includes a language reference.

The HP Instrument BASIC User’s Handbook Supplement shows how to use HP Instrument BASIC to program the analyzer.

The Option 100 Fault Location and Structural Return Loss Measurements User’s Guide Supplement provides theory and measurement examples for making fault location and SRL measurements. (Shipped only with Option 100 analyzers.)

The CATV Quick Start Guide provides abbreviated instructions for testing the quality of coaxial cables. (Shipped only with Option 100 analyzers.)

The Cellular Antenna Quick Start Guide provides abbreviated instructions for verifying the performance of cellular antenna systems. (Shipped only with Option 100 analyzers.)

vi Programmer’ s Guide

Contents

1. Introduction to HP-IB Programming

Introduction to HP-IB Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2

Bus Structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-4

Data Bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-4

Handshake Lines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-4

Control Lines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-5

Sending Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-6

HP-IB Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-7

Interface Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-8

Programming Fundamentals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-9

Controller Capabilities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-9

Response to Bus Management Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-10

Message Exchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-13

2. Synchronizing the Analyzer and a Controller

Synchronizing the Analyzer and a Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2

Overlapped Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3

Controlling Execution of Overlapped Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6

Using *WAI and *OPC? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-8

3. Passing Control

Passing Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2

4. Data Types and Encoding

Data Types and Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2

Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3

Numeric Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3

Character Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3

String Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-4

Expression Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-4

Block Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-4

Data Encoding for Large Data Transfers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-6

ASCII Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-7

Binary Encoding. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-7

Byte Swapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-7

Programmer’s Guide Contents-vii

Contents

5. Using Status Registers

Using Status Registers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-2

General Status Register Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-3

Condition Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-4

Transition Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-4

Event Register. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-4

Enable Register. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-5

How to Use Registers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-6

The Service Request Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-7

Generating a Service Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-8

The Analyzer's Status Register Sets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-10

Status Byte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-12

Device Status Register Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-15

Limit Fail Register Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-16

Questionable Status Register Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-19

Standard Event Status Register Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-20

Measuring Status Register Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-23

Averaging Status Register Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-23

Operational Status Register Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-24

Settings for STATus:PRESet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-25

Analyzer Register Set Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-26

6. Trace Data Transfers

Trace Data Transfers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-2

Querying the Measurement Trace Using BASIC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-3

Smith Chart and Polar Formats. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-4

Querying the Measurement Trace Using SICL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-5

Using Binary Data Encoding. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-6

Trace Data Transfer Sizes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-8

Transferring Data with IBASIC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-10

Taking Sweeps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-11

CALC:DATA? versus TRACE:DATA? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-12

Querying Single Data Points Using Markers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-13

Accessing Other Measurement Arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-14

Applying Gain Correction Using the Memory Trace . . . . . . . . . . . . . . . . . . . . . . . . . .6-16

Performing Your Own Data Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-18

Contents-viii Pr ogrammer’s Guide

Contents

Downloading Trace Data Using Binary Encoding. . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-20

Internal Measurement Arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-21

Raw Data Arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-22

Ratio Calculations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-22

Error Correction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-23

Error Coefﬁcient Arrays. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-23

Averaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-25

Corrected Data Arrays. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-25

Corrected Memory Arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-25

Trace Math Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-26

Electrical Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-26

Transform (Option 100 only) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-26

Formatting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-26

Formatted Arrays. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-26

Offset and Scale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-27

7. Using Graphics

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-2

Window Geometry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-4

The Graphics Buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-6

8. Front Panel Keycodes

Front Panel Keycodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-2

Controlling the Front Panel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-2

Monitoring the Front Panel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-2

9. Introduction to SCPI

Introduction to SCPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-2

The Command Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-3

Sending Multiple Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-7

Command Abbreviation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-8

Implied Mnemonics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-9

Parameter Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-10

Numeric Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-10

Character Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-11

Boolean Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-12

Programmer’s Guide Contents-ix

Contents

String Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-13

Block Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-13

Syntax Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-14

IEEE 488.2 Common Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-16

10. Menu Map with SCPI Commands

How to Enter Numbers and Characters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-4

How to Enter Frequency Values. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-5

How to Enter Time Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-6

How to Enter Power and Voltage Values. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-7

How to Enter Text. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-8

Menu Map for HP 8712ET/ES and HP 8714ET/ES . . . . . . . . . . . . . . . . . . . . . . . . . . .10-9

11. SCPI Command Summary

Queries, Forms, and Parameter Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-2

Parameter Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-3

SCPI Device Command Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-4

12. SCPI Conformance Information

SCPI Conformance Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-2

SCPI Standard Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-3

Instrument Speciﬁc Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-10

13. SCPI Error Messages

SCPI Error Messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-2

Command Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-3

Execution Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-8

Device-Speciﬁc Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-15

Query Errors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-17

Contents-x Programmer’ s Guide

1 Introduction to HP-IB

Programming

1-1

Introduction to HP-IB Programming

HP-IB

Introduction to HP-IB Programming

HP-IB—the Hewlett-Packard Interface Bus—is a high-performance bus that connects individual instruments and computers together to make integrated test systems. The bus and its associated interface operations are deﬁned by the IEEE 488.1 standard. The IEEE 488.2 standard deﬁnes the interface capabilities of instruments and controllers in a measurement system, including some frequently used commands.

HP-IB cables provide the physical link between devices on the bus. There are eight data lines on each cable that are used to send data from one device to another. Devices that send data over these lines are called Talkers. Listeners are devices that receive data over the same lines. There are also ﬁve control lines on each cable that are used to manage trafﬁc on the data lines and to control other interface operations. Controllers are devices that use these control lines to specify the talker and listener in a data exchange. When an HP-IB system contains more that one device with controller capabilities, only one of the devices is allowed to control data exchanges at any given time. The device currently controlling data exchanges is called the Active Controller. Also, only one of the controller-capable devices can be designated as the System Controller, the one device that can take control of the bus even if it is not the active controller. The network analyzer can act as a talker, listener, active controller or system controller at different times.

HP-IB addresses provide a way to identify devices on the bus. Each device on the bus must have a unique address. The active controller uses HP-IB addresses to specify which device talks and which device listens during a data exchange. Device addresses are set on each device using either a front-panel key sequence or a rear-panel switch.

To set the HP-IB address on the analyzer, use the softkeys located in the

SYSTEM OPTIONS

analyzer is 16.

1-2 Programmer’ s Guide

menu. The factory default address for the

Introduction to HP-IB Programming

Softkey

Introduction to HP-IB Programming

NOTE Throughout this manual, the following conventions are used:

• Square brackets ([ ]) are used to enclose a keyword that is optional or implied when programming the command; that is, the instrument will process the command to have the same effect whether the option node is omitted or not.

• Parameter types (< >) are distinguished by enclosing the type name in angle brackets.

• A vertical bar (|) can be read as “or” and is used to separate alternative parameter options.

• A is a labeled button on the instrument front panel.

• A is one of the eight unlabeled buttons along the right side

HARDKEY

of the instrument display. The function of each is indicated next to the on the instrument display.

Programmer’s Guide 1-3

Introduction to HP-IB Programming

Bus Structure

Data Bus

The data bus consists of eight lines that are used to transfer data from one device to another. Programming commands and data sent on these lines are typically encoded in the ASCII format, although binary encoding is often used to speed up the transfer of large arrays. Both ASCII and binary data formats are available to the analyzer. In addition, every byte transferred over HP-IB undergoes a handshake to ensure valid data.

Handshake Lines

A three-line handshake scheme coordinates the transfer of data between talkers and listeners. This technique forces data transfers to occur at the speed of the slowest device, and ensures data integrity in multiple listener transfers. With most computing controllers and instruments , the handshake is performed automatically, which makes it transparent to the programmer.

1-4 Programmer’ s Guide

Introduction to HP-IB Programming

Return to Local

Bus Structure

Control Lines

The data bus also has ﬁve control lines that the controller uses both to send bus commands and to address devices:

IFC Interface Clear. Only the system controller uses this

line. When this line is true (low), all devices (addressed or not) are deselected, and go to an idle state.

ATN Attention. The active controller uses this line to deﬁne

whether the information on the data bus is a command or is data. When this line is true (low), the bus is in the command mode and the data lines carry bus commands. When this line is false (high), the bus is in the data mode and the data lines carry device-dependent instructions or data.

SRQ Service Request. This line is set true (low) when a

device requests service: the active controller services the requesting device. The analyzer can set the SRQ line true (low) for a variety of reasons.

REN Remote Enable. Only the system controller uses this

line. When this line is set true (low), the bus is in the remote mode and devices are addressed either to listen or talk. When the bus is in remote mode and a device is addressed, the device receives instructions from HP-IB rather than from its front panel (pressing the

softkey returns the device to front panel operation). When this line is set false (high), the bus and all devices return to local operation.

EOI End or Identify. This line is used by a talker to indicate

the last data byte in a multiple byte transmission, or by an active controller to initiate a parallel poll sequence. The analyzer recognizes the EOI line as a terminator and it sets the EOI line true (low) with the last byte of a message output (data, markers, plots, prints, error messages). The analyzer does not respond to parallel poll.

Programmer’s Guide 1-5

Introduction to HP-IB Programming

Sending Commands

Commands are sent over the HP-IB via a controller's language system, such as IBASIC, Quic kBASIC or C. The keywords used by a controller to send HP-IB commands vary among systems. When determining the correct keywords to use, keep in mind that there are two different kinds of HP-IB commands:

• Bus management commands, which control the HP-IB interface.

• Device commands, which control analyzer functions. Language systems usually deal differently with these two kinds of HP-IB

commands. For example, HP BASIC uses a unique keyword to send each bus management command, but always uses the keyword OUTPUT to send device commands.

The following example shows how to send a typical device command:

OUTPUT 716;"CALCULATE:MARKER:MAXIMUM"

This sends the command CALCULATE:MARKER:MAXIMUM to the HP-IB device at address 716. If the device is an analyzer, the command instructs the analyzer to set a marker to the maximum point on the data trace.

1-6 Programmer’ s Guide

Introduction to HP-IB Programming

HP-IB Requirements

Number of Interconnected Devices:

15 maximum

Interconnection Path/Maximum Cable Length:

20 meters maximum or 2 meters per device, whichever is less.

Message Transfer Scheme:

Byte serial/bit parallel asynchronous data transfer using a 3-line handshake system.

Data Rate:

Maximum of 1 megabyte per second over limited distances with tri-state drivers. The actual data rate is the transfer rate of the slowest device involved.

HP-IB Requirements

Address Capability:

Primary addresses: 31 talk, 31 listen. A maximum of 1 talker and 14 listeners at one time.

Multiple Controller Capability:

In systems with more than one controller (like the analyzer system), only one can be active at a time. The active controller can pass control to another controller, but only the system controller can assume unconditional control. Only one system controller is allowed. The system controller is hard-wired to assume bus control after a power failure.

Programmer’s Guide 1-7

Introduction to HP-IB Programming

Interface Capabilities

The analyzer has the following interface capabilities, deﬁned by the IEEE 488.1 standard:

Table 1-1 Analyzer Interface Capabilities (IEEE 488.1)

SH1 full Source handshake capability AH1 full Acceptor handshake capability T6 basic Talker, Serial Poll, no Talk Only, unaddress if MLA TE0 no Extended Talker capability L4 basic Listener, no Listen Only, unaddress if MTA LE0 no Extended Listener capability SR1 full Service Request capability RL1 full Remote/Local capability DC1 full Device Clear capability C1 System Controller capability C2 send IFC and take charge Controller capability C3 send REN Controller capability

C8 C12 E2 tri-state drivers DT1 full device trigger capability PP0 no parallel poll capability

1. only when an HP Instrument BASIC program is running

2. only when an HP Instrument BASIC program is not running

1-8 Programmer’ s Guide

respond to SRQ send IFC, receive control, pass control, pass control to self

send IF messages, receive control, pass control

Introduction to HP-IB Programming

System Controller

Talker Listener

HP-IB

Programming Fundamentals

This section includes speciﬁc information for programming your network analyzer. It includes how the analyzer interacts with a controller, how data is transferred between the analyzer and a controller , and how to use the analyzer's status register structure to generate service requests.

Controller Capabilities

The analyzer can be conﬁgured as an HP-IB system controller or as a talker/listener on the bus. To conﬁgure the analyzer, select either the

or the softkey in the

SYSTEM OPTIONS

The analyzer is not usually conﬁgured as the system controller unless it is the only controller on the bus. This setup would be used if the analyzer only needed to control printers or plotters. It would also be used if HP Instrument BASIC was being used to control other test equipment.

When the analyzer is used with another controller on the bus, it is usually conﬁgured as a talker/listener. In this conﬁguration, when the analyzer is given control it can function as the active controller.

menu.

Programmer’s Guide 1-9

Introduction to HP-IB Programming

Programming Fundamentals

Response to Bus Management Commands

The HP-IB contains an attention (ATN) line that determines whether the interface is in command mode or data mode. When the interface is in command mode (ATN TRUE), a controller can send bus management commands over the bus. Bus management commands specify which devices on the interface can talk (send data) and which can listen (receive data). They also instruct devices on the bus, either individually or collectively, to perform a particular interface operation.

This section describes how the analyzer responds to the HP-IB management commands. The commands themselves are deﬁned by the IEEE 488.1 standard. Refer to the documentation for your controller's language system to determine how to send these commands.

Device Clear (DCL)

When the analyzer receives this command, it does the following:

• clears its input and output queues

• resets its command parser (so it is ready to receive a new program message)

• cancels any pending *OPC command or query

The command does not affect the following:

• front panel operation

• any analyzer operations in progress (other than those already mentioned)

• any instrument settings or registers (although clearing the output queue may indirectly affect the status byte's Message Available (MAV) bit)

Go To Local (GTL)

This command returns the analyzer to local (front-panel) control. All keys on the analyzer's front-panel are enabled.

1-10 Programmer’ s Guide

Introduction to HP-IB Programming

Return to Local

Programming Fundamentals

Interface Clear (IFC)

This command causes the analyzer to halt all bus activity. It discontinues any input or output, although the input and output queues are not cleared. If the analyzer is designated as the active controller when this command is received, it relinquishes control of the bus to the system controller. If the analyzer is enabled to respond to a Serial Poll, it becomes Serial Poll disabled.

Local Lockout (LLO)

This command causes the analyzer to enter the local lockout mode, regardless of whether it is in the local or remote mode. The analyzer only leaves the local lockout mode when the HP-IB Remote Enable (REN) line is set FALSE.

Local Lockout ensures that the analyzer's remote softkey menu (including the softkey) is disabled when the analyzer is in the remote mode. When the key is enabled, it allows a front-panel operator to return the analyzer to local mode, enabling all other front-panel keys. When the key is disabled, it does not allow the front-panel operator to return the analyzer to local mode.

Parallel Poll

The analyzer ignores all of the following parallel poll commands:

• Parallel Poll Conﬁgure (PPC)

• Parallel Poll Unconﬁgure (PPU)

• Parallel Poll Enable (PPE)

• Parallel Poll Disable (PPD)

Programmer’s Guide 1-11

Introduction to HP-IB Programming

Return to Local

Programming Fundamentals

Remote Enable (REN)

REN is a single line on the HP-IB. When it is set TRUE, the analyzer will enter the remote mode when addressed to listen. It will remain in remote mode until it receives the Go to Local (GTL) command or until the REN line is set FALSE.

When the analyzer is in remote mode and local lockout mode, all front panel keys are disabled. When the analyzer is in remote mode but not in local lockout mode, all front panel keys are disabled except for the softkeys. The remote softkey menu includes seven keys that are available for use by a program. The eighth softkey is the

key which allows a front-panel operator to return the

analyzer to local mode, enabling all other front-panel keys.

Selected Device Clear (SDC)

The analyzer responds to this command in the same way that it responds to the Device Clear (DCL) command.

When the analyzer receives this command it does the following:

• clears its input and output queues

• resets its command parser (so it is ready to receive a new program message)

• cancels any pending *OPC command or query

The command does not affect the following:

• front-panel operation

• any analyzer operations in progress (other than those already mentioned)

• any analyzer settings or registers (although clearing the output queue may indirectly affect the status byte's MAV bit) passed

Serial Poll

The analyzer responds to both of the serial poll commands. The Serial Poll Enable (SPE) command causes the analyzer to enter the serial poll mode. While the analyzer is in this mode, it sends the contents of its status byte register to the controller when addressed to talk.

1-12 Programmer’ s Guide

Introduction to HP-IB Programming

Programming Fundamentals

When the status byte is returned in response to a serial poll, bit 6 acts as the Request Service (RQS) bit. If the bit is set, it will be cleared after the status byte is returned.

The Serial Poll Disable (SPD) command causes the analyzer to leave the serial poll mode.

Take Control Talker (TCT)

If the analyzer is addressed to talk, this command causes it to take control of the HP-IB. It becomes the active controller on the bus. The analyzer automatically passes control back when it completes the operation that required it to take control. Control is passed back to the address speciﬁed by the *PCB command (which should be sent prior to passing control).

If the analyzer does not require control when this command is received, it immediately passes control back.

Message Exchange

The analyzer communicates with the controller and other devices on the HP-IB using program messages and response messages. Program messages are used to send commands, queries, and data to the analyzer.

Response messages are used to return data from the analyzer. The syntax for both kinds of messages is discussed in Chapter 9,

“Introduction to SCPI.”

There are two important things to remember about the message exchanges between the analyzer and other devices on the bus:

• The analyzer only talks after it receives a terminated query (see

“Query Response Generation” on page 1-16).

• Once it receives a terminated query, the analyzer expects to talk before it is told to do something else.

Programmer’s Guide 1-13

Introduction to HP-IB Programming

Programming Fundamentals

HP-IB Queues

Queues enhance the exchange of messages between the analyzer and other devices on the bus. The analyzer contains the following:

• an input queue

• an error queue

• an output queue

Input Queue

The input queue temporarily stores the following until they are read by the analyzer's command parser:

• device commands and queries

• the HP-IB END message (EOI asserted while the last data byte is on the bus)

The input queue also makes it possible for a controller to send multiple program messages to the analyzer without regard to the amount of time required to parse and execute those messages. The queue holds up to 128 bytes. It is cleared when the following actions occur:

• the analyzer is turned on

• the Device Clear (DCL) or Selected Device Clear (SDC) command is received

Error Queue

The error queue temporarily stores up to 20 error messages. Each time the analyzer detects an error , it places a message in the queue . When you send the SYST:ERR? query, one message is moved from the error queue to the output queue so it can be read by the controller. Error messages are delivered to the output queue in the order they were received.

The error queue is cleared when the following actions occur:

• all the error messages are read using the SYST:ERR? query

• the analyzer is turned on

• the *CLS command is received

1-14 Programmer’ s Guide

Introduction to HP-IB Programming

Programming Fundamentals

Output Queue

The output queue temporarily stores a single response message until it is read by a controller. It is cleared when the following actions occur:

• the message is read by a controller

• the analyzer is turned on

• the Device Clear (DCL) or Selected Device Clear (SDC) command is received

Command Parser

The command parser reads program messages from the input queue in the order they were received from the bus. It analyzes the messages to determine what actions the analyzer should take.

One of the parser's most important functions is to determine the position of a program message in the analyzer's command tree (described in

Chapter 9). When the command parser is reset, the next command it

receives is expected to arise from the base of the analyzer's command tree.

The parser is reset when the following actions occur:

• the analyzer is turned on

• The Device Clear (DCL) or Selected Device Clear (SDC) command is received.

• a colon immediately follows a semicolon in a program message. (For more information see “Sending Multiple Commands” on page 9-7.)

• A program message terminator is received. A program message terminator can be an ASCII carriage return ( or the HP-IB END message (EOI set true).

Programmer’s Guide 1-15

) or newline character

Introduction to HP-IB Programming

Programming Fundamentals

Query Response Generation

When the analyzer parses a query, the response to that query is placed in the analyzer's output queue. The response should be read immediately after the query is sent. This ensures that the response is not cleared before it is read. The response is cleared when one of the following message exchange conditions occurs:

• Unterminated condition—the query is not properly terminated with an ASCII carriage return character or the HP-IB END message (EOI set true) before the response is read.

• Interrupted condition—a second program message is sent before the response to the ﬁrst is read.

• Buffer deadlock—a program message is sent that exceeds the length of the input queue or that generates more response data than ﬁts in the output queue.

1-16 Programmer’ s Guide

2 Synchronizing the Analyzer and

a Controller

2-1

Synchronizing the Analyzer and a Controller

The IEEE 488.2 standard provides tools that can be used to synchronize the analyzer and a controller. Proper use of these tools ensures that the analyzer is in a known state when you send a particular command or query.

Device commands can be divided into two broad classes:

• Sequential commands

• Overlapped commands

Most of the analyzer's commands are processed sequentially. A sequential command holds off the processing of subsequent commands until it has been completely processed.

Some commands do not hold off the processing of subsequent commands; they are called overlapped commands.

2-2 Programmer’ s Guide

Synchronizing the Analyzer and a Controller

Overlapped Commands

Typically, overlapped commands take longer to process than sequential commands. F or example, theINITIATE:IMMEDIATE command restarts a measurement. The command is not considered to have been completely processed until the measurement is complete. This can take a long time with a narrow or ﬁne system bandwidth or when averaging is enabled.

The analyzer has the following overlapped commands:

ABORt CALibration:SELF: ALL CALibration:SELF: <ON|OFF|ONCE> CALibration:SELF:METHod:<ONEPort|TWOPort> CALibration:ZERO:AUTO CONFigure[1|2] DIAGnostic:CCONstants:LOAD DIAGnostic:CCONstants:STORe:DISK DIAGnostic:CCONstants:STORe:EEPRom DIAGnostic:DITHer DIAGnostic:SPUR:AVOid HCOPy[:IMMediate] INITiate[1|2]:CONTinuous INITiate[1|2][:IMMediate] MMEMory:LOAD:STATe OUTPut[:STATe] POWer[1|2]:MODE PROGram[:SELected]:EXECute ROUTe[1|2]:PATH:DEFine:PORT? ROUTe[1|2]:PATH:DEFine:PORT <num1>, <num2> ROUTe[1|2]:REFLection:DEFine:PORT <num>

Programmer’s Guide 2-3

Synchronizing the Analyzer and a Controller

Overlapped Commands

2-4 Programmer’ s Guide

Synchronizing the Analyzer and a Controller

Overlapped Commands

only) SENSe:ROSCillator:SOURce SENSe[1|2]:STATe SENSe[1|2]:SWEep:POINts SENSe[1|2]:SWEep:TIME SENSe[1|2]:SWEep:TIME:AUTO SENSe:SWEep:TRIGger:SOURce SOURce[1|2]:POWer[:LEVel][:IMMediate][:AMPLitude] SYSTem:PRESet TRACe[:DATA] TRACe:CORRection:SIMulate:SAVE-?<TRANsmission1|...> TRIGger[:SEQuence]:SOURce

Programmer’s Guide 2-5

Synchronizing the Analyzer and a Controller

Controlling Execution of Overlapped Commands

Each overlapped command is executed in two stages: initiation and completion. When both stages are complete for a given command, the command has “completed execution.”

*WAI Holds off the processing of subsequent commands until

the initiation stage of all preceding commands is ﬁnished. If used after each overlapped command, this command ensures that commands in the analyzer’s input queue complete initiation in the order received.

Use of the *WAI command is explained later in this section and is demonstrated in the SETUP example program.

*OPC? Places a 1 in the analyzer's output queue when all

preceding commands have completed execution. If the program reads the output queue before it continues, this effectively pauses the controller until all executing overlapped commands are completed. This command is generally preferred to *WAI for control of command execution.

Use of the *OPC? command is explained later in this chapter and is demonstrated in the TRANCAL and

REFLCAL example programs.

*OPC Sets bit 0 of the Standard Event Status event register

to 1 when all preceding commands have completed execution. The analyzer's status registers can then be used to generate a service request when all overlapped commands are completed. This synchronizes the controller to the completion of an overlapped command, but also leaves the controller free to perform other tasks while the command is executing within the analyzer.

2-6 Programmer’ s Guide

Synchronizing the Analyzer and a Controller

Controlling Execution of Overlapped Commands

NOTE *OPC only informs you when all currently executing commands have

completed execution. It does not hold off the processing of subsequent commands. No commands should be sent to the analyzer between sending the *OPC command and receiving the service request. Any commands sent will be executed and may affect how the instrument responds to the previously sent *OPC.

The *CLS and *RST commands cancel any preceding *OPC? or *OPC. Executing overlapped commands are still completed, but their completion is not reported in either the status register or the output queue. Two HP-IB bus management commands — Device Clear (DCL) and Selected Device Clear (SDC) — also cancel any preceding *OPC? or

*OPC.

NOTE Use *WAI, *OPC? or *OPC whenever overlapped commands are used. A

recommended technique is to send *OPC? at the end of each group of commands.

CAUTION ALWAYS trigger an individual sweep (using *OPC? and waiting for the

reply) before reading data over the bus or executing a marker function. The analyzer has the ability to process the commands it receives faster than it can make a measurement. If the measurement is not complete when the data is read or a marker search function is executed, the results are invalid.

The command to use (in an IBASIC OUTPUT statement) is:

OUTPUT @Hp8711;"ABOR;:INIT:CONT OFF;:INIT;*OPC?" ENTER @Hp8711;Opc_done

or another form of the INITiate[1|2][:IMMediate] command combined with the *OPC? query.

Refer to “Taking Sweeps” in the Example Programs Guide for more information.

Programmer’s Guide 2-7

Synchronizing the Analyzer and a Controller

Controlling Execution of Overlapped Commands

Using WAI and OPC?

*WAI

The following example describes the use of the *WAI command. For this discussion, remember that a sequential command holds off the processing of subsequent commands until it has been completely processed. An overlapped command does not.

10 OUTPUT @Rfna;"command1" 20 OUTPUT @Rfna;"command2;*WAI" 30 OUTPUT @Rfna;"command3;" 40 OUTPUT @Rfna;"command4" 50 END

In the example above, commands are sent and completed in the following order:

• Commands 1 through 4 are sent to the analyzer as fast as the HP-IB bus trafﬁc will allow. The program sending the commands may very well end before any command has been completed.

• Command 1 begins execution ﬁrst.

• If both commands 1 and 2 are overlapped types, the order in which they ﬁnish initiation depends on the commands. The order of completion is unknown.

• Commands 3 and 4 will not be started until both commands 1 and 2 have ﬁnished initiation.

• Command 3 will begin execution before command 4.

• If all four commands are overlapped types, the order in which they complete execution is unknown.

NOTE Because *WAI only controls the order of the initiation stage of

commands, rather than the order of completion, it is strongly recommended that *OPC? be used whenever sequential operation of overlapping commands is required.

2-8 Programmer’ s Guide

Synchronizing the Analyzer and a Controller

Controlling Execution of Overlapped Commands

*OPC

The following example describes the use of the *OPC? command. For this discussion, remember that a sequential command holds off the processing of subsequent commands until it has been completely processed. An overlapped command does not.

10 OUTPUT @Rfna;"command1" 20 OUTPUT @Rfna;"command2;*OPC?" 30 ENTER @Rfna;Opc_done 40 OUTPUT @Rfna;"command3;" 50 OUTPUT @Rfna;"command4;*OPC?" 60 ENTER @Rfna;Opc_done 70 END

In the example above, commands are sent and completed in the following order:

• Commands 1 and 2 are sent to the analyzer as fast as the HP-IB bus trafﬁc will allow.

• Command 1 will begin execution before command 2.

• If both commands 1 and 2 are overlapped commands, the order of command completion is unknown.

• When both commands 1 and 2 have completed execution, commands 3 and 4 will be sent to the analyzer as fast as the HP-IB bus trafﬁc will allow.

• Command 3 will begin execution before command 4.

• If both commands 3 and 4 are overlapped commands, the order of command completion is unknown.

• This program will not end until the Opc_done, located in line 60, is returned indicating that both commands have completed execution.

Use *OPC? to ensure commands complete before proceeding.

*OPC? command, and reads the analyzer response with ENTER:

100 Command_done !Example of subroutine using *OPC? 110 OUTPUT @Rfna;"*OPC?" 120 ENTER @Rfna;Opc_done 130 RETURN

Call the Command_done subroutine after each overlapped command to ensure the desired order of command execution.

Programmer’s Guide 2-9

This can be done by calling a subroutine that issues the

Synchronizing the Analyzer and a Controller

Controlling Execution of Overlapped Commands

2-10 Programmer’ s Guide

3 Passing Control

3-1

Passing Control

When an external controller is connected to the analyzer with an HP-IB cable, passing control may be needed to control devices such as printers and plotters that are also connected on the HP-IB. For some operations the active controller must pass control to the analyzer. When the analyzer completes the operation, it automatically passes control of the bus back to the external controller.

An example program, PASSCTRL, demonstrates passing control to the analyzer. In this example program, control is passed so the analyzer can control a printer for hardcopy output. See the Example Programs Guide.

NOTE Pass Control is not needed to control peripherals connected to the serial,

parallel, or LAN ports. For smooth passing of control, take steps that ensure the following

conditions are met:

• The analyzer must know the controller's address so it can pass control back.

• The controller must be informed when the analyzer passes control back.

3-2 Pr ogrammer’s Guide

Passing Control

The following is a procedure for passing control:

1. Send the controller's HP-IB address to the analyzer with the *PCB command.

2. Clear the analyzer's status registers with the *CLS command.

3. Enable the analyzer's status registers to generate a service request when the Operation Complete bit is set. (Send *ESE with a value of 1 and *SRE with a value of 32.)

4. Enable the controller to respond to the service request.

5. Send the command that requires control of the bus followed by the *OPC command.

6. Pass control to the analyzer and wait for the service request. The service request indicates that the command has been completed and control has been passed back to the controller.

NOTE For this procedure to work properly, only the command that requires

control of the bus should be pending. Other overlapped commands should not. For more information on overlapped commands, see Chapter 2,

“Synchronizing the Analyzer and a Controller.”

Programmer’s Guide 3-3

Passing Control

3-4 Pr ogrammer’s Guide

4 Data Types and Encoding

4-1

Data Types and Encoding

Data is transferred between the analyzer and a controller via the HP-IB data lines, DIO1 through DIO8. Such transfers occur in a byte-serial (one byte at a time), bit-parallel (8 bits at a time) manner. This section discusses the following aspects of data transfer:

• the different data types used during data transfers

• data encoding used during transfers of numeric block data

4-2 Pr ogrammer’s Guide

Data Types and Encoding

Data Types

The analyzer uses a number of different data types during data transfers. Data transfer occurs in response to a query. The data type used is determined by the parameter being queried. Data types described in this section are:

• Numeric Data

• Character Data

• String Data

• Expression Data

• Block Data

Numeric Data

The analyzer returns three types of numeric data in response to queries:

NR1 data Integers (such as +1, 0, -1, 123, -12345). This is the

response type for boolean parameters as well as some numeric parameters.

NR2 data Floating point numbers with an explicit decimal point

(such as 12.3, +1.234, -0.12345).

NR3 data Floating point numbers in scientiﬁc notation (such as

+1.23E+5, +123.4E-3, -456.789E+6).

Character Data

Character data consists of ASCII characters grouped together in mnemonics that represent speciﬁc instrument settings (such as

MAXimum, MINimum or MLOGarithmic). The analyzer always returns the short form of the mnemonic in upper-case alpha characters.

Programmer’s Guide 4-3

Data Types and Encoding

Data Types

String Data

String data consists of ASCII characters. The string must be enclosed by a delimiter, either single quotes ('This is string data.') or double quotes (“This is also string data.”). To include the delimiter as a character in the string, it must be typed twice without any characters in between. The analyzer always uses double quotes when it returns string data.

Expression Data

Expression data consists of mathematical expressions that use character parameters. When expression data is sent to the analyzer, it is always enclosed in parentheses (such as (IMPL/CH1SMEM) or (IMPL)). The analyzer returns expression data enclosed in double quotes.

Block Data

The block data mode is typically used to transfer large quantities of related data (like a data trace). Blocks can be sent as deﬁnite length blocks or indeﬁnite length blocks — the instrument will accept either form. The analyzer always returns deﬁnite length block data in response to queries.

Deﬁnite Block Length

The general form for a deﬁnite block length transfer is:

#<num_digits><num_bytes><data_bytes>

In the deﬁnite length block, two numbers must be speciﬁed. The single decimal digit <num_digits> speciﬁes how many digits are contained in <num_bytes>. The decimal number <num_bytes> speciﬁes how many data bytes will follow in <data_bytes>. An example IBASIC (or HP BASIC) statement to send ABC+XYZ as a deﬁnite block length parameter is shown; note that the data block contains seven bytes (7) and only one digit is needed to describe the block length 1.

OUTPUT 716;"#17ABC+XYZ"

4-4 Pr ogrammer’s Guide

Data Types and Encoding

Data Types

NOTE This analyzer will send an additional <

> with EOI asserted for deﬁnite

block length transfers. The deﬁnite length block form for your analyzer is: #<num_digits><num_bytes><data_bytes><

<num_bytes> is the number of <data_bytes> without counting

><EOI>.

Indeﬁnite Block Length

The general form for an indeﬁnite block length transfer is:

#0<data_bytes><

After the last data byte is sent, the indeﬁnite length block must be terminated by sending a carriage return or newline with EOI asserted. This forces the termination of the program message. An example IBASIC (or HP BASIC) statement to send ABC+XYZ as an indeﬁnite block length parameter is shown; note that END is used to properly terminate the message.

OUTPUT 716;"#0ABC+XYZ",END

NOTE Files are transferred as indeﬁnite length blocks.

><EOI>

><EOI>.

Programmer’s Guide 4-5

Data Types and Encoding

Data Encoding for Large Data Transfers

The FORMat:DATA command selects the type of data and the type of data encoding that is used to transfer large blocks of numeric data between the analyzer and a controller. There are two block speciﬁers and one numeric data type speciﬁer:

REAL speciﬁes the block data type. Either the deﬁnite or

indeﬁnite length syntax can be used. The block is transferred as a series of binary-encoded ﬂoating-point numbers. Data transfers of the REAL,64 data type are demonstrated in the REALDATA example program.

INTeger speciﬁes the block data type. Either the deﬁnite or

indeﬁnite length syntax can be used. The block is transferred as an array of binary-encoded data with each point represented by a set of four 16-bit integers. This is the instrument's internal format — it should only be used for data that will be returned to the instrument for later use. Data transfers of the

INTeger 16 data type are demonstrated in the INTDATA and LOADCALS example programs.

ASCii speciﬁes the numeric data type (NR1, NR2 or NR3

syntax). The data is transferred as a series of ASCII-encoded numbers separated by commas. ASCii formatted data transfers are demonstrated in the ASCDATA example program.

Blocks that contain mixed data — both numbers and ASCII characters — ignore the setting of FORMat:DATA. These blocks always transfer as either deﬁnite length or indeﬁnite length block data. The following commands transfer blocks of mixed data:

PROGram[:SELected]:DEFine SYSTem:SET

CAUTION INTeger 16 data for the HP8711/12/13/14/ A-, B-, and C-series

instruments is represented by sets of three 16-bit integers. The HP8712ET/ES and HP8714ET/ES instruments use sets of four 16-bit integers.

4-6 Pr ogrammer’s Guide

Data Types and Encoding

Data Encoding for Large Data Transfers

ASCII Encoding

The ANSI X3.4-1977 standard deﬁnes the ASCII 7-bit code. When an ASCII-encoded byte is sent over the HP-IB, bits 0 through 6 of the byte (bit 0 being the least signiﬁcant bit) correspond to the HP-IB data lines DIO1 through DIO7. DIO8 is ignored.

When ASCII encoding is used for large blocks of data, the number of signiﬁcant digits to be returned for each number in the block can be speciﬁed. For example, the following command returns all numbers as NR3 data with 7 signiﬁcant digits.

FORMat:DATA ASCii,7

Binary Encoding

When binary encoding is used for large blocks of data, all numbers in the block are transferred as 32-bit or 64-bit binary ﬂoating point numbers or as an array of 16-bit integers. The binary ﬂoating-point formats are deﬁned in the IEEE 754-1985 standard.

FORMat:DATA REAL,32 selects the IEEE 32-bit format (not

supported by IBASIC or HP BASIC)

FORMat:DATA REAL,64 selects the IEEE 64-bit format. FORMat:DATA INTeger,16 selects the 16-bit integer format.

Byte Swapping

PC compatibles frequently use a modiﬁcation of the IEEE ﬂoating point formats with the byte order reversed. To reverse the byte order for data transfer into a PC, the FORMat:BORDer command should be used.

FORMat:BORDer SWAPped selects the byte-swapped format FORMat:BORDer NORMal selects the standard format

Programmer’s Guide 4-7

Data Types and Encoding

Data Encoding for Large Data Transfers

4-8 Pr ogrammer’s Guide

5 Using Status Registers

5-1

Using Status Registers

The analyzer's status registers contain information about the condition of the network analyzer and its measurements. This section describes the registers and their use in HP-IB programming.

Example programs using the status registers are included in the Example Programs Guide. These programs include SRQ and GRAPHICS which use service request interrupt routines, PASSCTRL which uses the status byte to request control of the HP-IB, and LIMITEST which uses the Limit Fail condition register.

5-2 Pr ogrammer’s Guide

General Status Register Model

The analyzer's status system is based on the general status register model shown in Figure 5-1. Most of the analyzer's register sets include all of the registers shown in the model, although commands are not always available for reading or writing a particular register. The information ﬂow within a register set starts at the condition register and ends at the register summary bit (see Figure 5-2 on page 5-5 for actual connections between the registers). This ﬂow is controlled by setting bits in the transition and enable registers.

Two register sets — the Status Byte and the Standard Event Status Register — are 8-bits wide. All others are 16-bits wide, but the most signiﬁcant bit (bit 15) in the larger registers is always set to 0.

Figure 5-1 General Status Register Model

Using Status Registers

General Status Register Model

Programmer’s Guide 5-3

Using Status Registers

General Status Register Model

Condition Register

Condition registers continuously monitor the instrument's hardware and ﬁrmware status. Bits in a condition register are not latched or buffered, they are updated in real time. When the condition monitored by a speciﬁc bit becomes true, the bit is set to 1. When the condition becomes false, the bit is reset to 0. Condition registers are read-only.

Transition Registers

Transition registers control what type of change in a condition register will set the corresponding bit in the event register. Positive state transitions (0 to 1) are only reported to the event register if the corresponding positive transition bit is set to 1. Negative state transitions (1 to 0) are only reported if the corresponding negative transition bit is set to 1. Setting both transition bits to 1 causes both positive and negative changes to be reported. Transition registers are read-write, and are unaffected by *CLS (clear status) or queries. They are reset to instrument default conditions at power up and after *RST and SYSTem:PRESet commands.

Event Register

Event registers latch any reported condition changes. When a transition bit allows a condition change to be reported, the corresponding event bit is set to 1. Once set, an event bit is no longer affected by condition changes. It remains set until the event register is cleared. Event registers are read-only.

An event register is cleared when you read it. All event registers are cleared when you send the *CLS (clear status) command.

5-4 Pr ogrammer’s Guide

Enable Register

Enable registers control the reporting of events (latched conditions) to the register summary bit. If an enable bit is set to 1, the corresponding event is included in the logical ORing process that determines the state of the summary bit. (The summary bit is only set to 1 if one or more enabled event bits are set to 1.) Summary bits are recorded in the instrument's status byte. Enable registers are read-write and are cleared by *CLS (clear status).

Figure 5-2 Flow of Information Within a Register Set

Using Status Registers

General Status Register Model

Programmer’s Guide 5-5

Using Status Registers

How to Use Registers

There are two methods of accessing the information in status registers:

• the direct-read method

• the service request (SRQ) method In the direct-read method, the analyzer is passive. It only tells the

controller that conditions have changed when the controller asks the right question. In the SRQ method, the analyzer is more active. It tells the controller when there has been a condition change without the controller asking. Either method allows you to monitor one or more conditions.

The following steps are used to monitor a condition with the direct read method:

1. Determine which register contains the bit that monitors the condition.

2. Send the unique HP-IB query that reads that register.

3. Examine the bit to see if the condition has changed.

The direct-read method works well when it is not necessary to know about changes the moment they occur. It does not work well if immediate knowledge of the condition change is needed. A program that used this method to detect a change in a condition would need to continuously read the registers at very short intervals. The SRQ method is better suited for that type of need.

5-6 Pr ogrammer’s Guide

Using Status Registers

The Service Request Process

The following steps are used to monitor a condition with the SRQ method:

1. Determine which bit monitors the condition.

2. Determine how that bit reports to the request service (RQS) bit of the Status Byte.

3. Send HP-IB commands to enable the bit that monitors the condition and to enable the summary bits that report the condition to the RQS bit.

4. Enable the controller to respond to service requests.

When the condition changes, the analyzer sets its RQS bit and the HP-IB's SRQ line. The controller is informed of the change as soon as it occurs. The time the controller would otherwise have used to monitor the condition can now be used to perform other tasks. The controller's response to the SRQ is determined by the program being run.

Programmer’s Guide 5-7

Using Status Registers

The Service Request Process

Generating a Service Request

A service request is generated using the Status Byte. As shown in Figure

5-3, the analyzer's other register sets report to the Status Byte. Some of

them report directly while others report indirectly through other register sets.

Figure 5-3 Generating a Service Request

5-8 Pr ogrammer’s Guide

Using Status Registers

The Service Request Process

The process of preparing the analyzer to generate a service request, and the handling of that interrupt when it is received by a program, are demonstrated in the SRQ example program.

When a register set causes its summary bit in the Status Byte to change from 0 to 1, the analyzer can initiate the service request (SRQ) process. If both the following conditions are true, the process is initiated:

• The corresponding bit of the Service Request enable register is also set to 1.

• The analyzer does not have a service request pending. (A service request is considered to be pending between the time the analyzer's SRQ process is initiated and the time the controller reads the Status Byte register with a serial poll.)

The SRQ process sets the HP-IB's SRQ line true and sets the Status Byte's request service (RQS) bit to 1. Both actions are necessary to inform the controller that the analyzer requires service. Setting the SRQ line informs the controller that some device on the bus requires service. Setting the RQS bit allows the controller to determine that the analyzer was the device that initiated the request.

When a program enables a controller to detect and respond to service requests, it should instruct the controller to perform a serial poll when the HP-IB's SRQ line is set true. Each device on the bus returns the contents of its Status Byte register in response to this poll. The device whose RQS bit is set to 1 is the device that requested service.

NOTE When the analyzer's Status Byte is read with a serial poll, the RQS bit is

reset to 0. Other bits in the register are not affected. As implied in Figure 5-3, bit 6 of the Status Byte register serves two

functions: the request service function (RQS) and the master summary status function (MSS). Two different methods for reading the register allow you to access the two functions. Reading the register with a serial poll allows you to access the bit's RQS function. Reading the register with *STB allows you to access the bit's MSS function.

Programmer’s Guide 5-9

Using Status Registers

The Analyzer's Status Register Sets

The analyzer uses eight register sets to keep track of instrument status: Status Byte *STB? and *SRE Device Status STATus:DEVice Limit Fail STATus:QUEStionable:LIMit Questionable

Status STATus:QUEStionable Standard Event

Status *ESR? and *ESE Measuring

Status STATus:OPERation:MEASuring Averaging

Status STATus:OPERation:AVERaging Operational

Status STATus:OPERation Their reporting structure is summarized in Figure 5-4. They are

described in greater detail in the following section.

NOTE Register bits not explicitly presented in the following sections are not

used by the analyzer. A query to one of these bits returns a value of 0.

5-10 Pr ogrammer’s Guide

Figure 5-4 Analyzer Register Sets

Using Status Registers

The Analyzer's Status Register Sets

Programmer’s Guide 5-11

Using Status Registers

The Analyzer's Status Register Sets

Status Byte

The Status Byte register set summarizes the states of the other register sets and monitors the analyzer's output queue. It is also responsible for generating service requests see “Generating a Service Request” on

page 5-8. See Figure 5-5.

Figure 5-5 The Status Byte Register Set

The Status Byte register set does not conform to the general status register model described at the beginning of this chapter. It contains only two registers: the Status Byte register and the Service Request enable register. The Status Byte register behaves like a condition register for all bits except bit 6. The Service Request enable register behaves like a standard enable register except that bit 6 is always set to 0.

5-12 Pr ogrammer’s Guide

Using Status Registers

The Analyzer's Status Register Sets

Bits in the Status Byte register are set to 1 under the following conditions:

Device Status Summary

(bit 2) is set to 1 when one or more enabled bits in the Device Status event register are set to 1.

Questionable Status Summary

(bit 3) is set to 1 when one or more enabled bits in the Questionable Status event register are set to 1.

Message Available

(bit 4) is set to 1 when the output queue contains a response message.

Standard Event Status Summary

(bit 5) is set to 1 when one or more enabled bits in the Standard Event Status event register are set to 1.

Master Summary Status

(bit 6, when read by *STB) is set to 1 when one or more enabled bits in the Status Byte register are set to 1.

Request Service

(bit 6, when read by serial poll) is set to 1 by the service request process (see “Generating a Service Request” on page 5-8).

Operational Status Summary

(bit 7) is set to 1 when one or more enabled bits in the Operational Status event register are set to 1.

Programmer’s Guide 5-13

Using Status Registers

The Analyzer's Status Register Sets

The commands used to read and write to the Status Byte registers are listed below:

SPOLL an IBASIC (or HP BASIC) command used in the

service request process to determine which device on the bus is requesting service.

*STB? reads the value of the instrument's status byte. This is

a non-destructive read—the Status Byte is cleared by the *CLS command.

*SRE <num> sets bits in the Service Request Enable register. The

current setting of the Service Request Enable register is stored in non-volatile memory. If *PSC has been set, it will be saved at power on.

*SRE? reads the current state of the Service Request Enable

5-14 Pr ogrammer’s Guide

Using Status Registers

The Analyzer's Status Register Sets

Device Status Register Set

The Device Status register set monitors the state of device-speciﬁc parameters.

Bits in the Device Status condition register are set to 1 under the following conditions:

Key Pressed

(bit 0) is set to 1 when one of the analyzer's front panel keys has been pressed.

Any Softkey Pressed

(bit 1) is set to 1 when one of the analyzer's softkeys has been pressed.

Any External Keyboard Key Pressed

(bit 2) is set to 1 when a key has been pressed on an external keyboard connected to the DIN KEYBOARD connector on the rear panel of the analyzer.

Front Panel Knob Turned

(bit 3) is set to 1 when the analyzer's front panel knob is turned.

Programmer’s Guide 5-15

Using Status Registers

The Analyzer's Status Register Sets

Limit Fail Register Set

The Limit Fail register set monitors limit test results for both measurement channels.

The inputs for the bits in the Limit Fail condition register are latched. (See Figure 5-6.) The two bits for measurement channel 1 are latched when the Limit Test is OFF for channel 1 or when MEAS 1 is OFF. The two bits for measurement channel 2 are latched when Limt Test is OFF for channel 2 or when MEAS 2 is OFF.

The following conditions determine the state for each of the bits when the corresponding Limit Test is ON.

Measurement Channel 1 Limit Failed

(bit 0) is set to 1 when limit testing is enabled and any point on measurement channel 1 fails the limit test, or when any enabled marker limit on measurement channel 1 has failed.

Measurement Channel 2 Limit Failed

(bit 1) is set to 1 when limit testing is enabled and any point on measurement channel 2 fails the limit test, or when any enabled marker limit on measurement channel 2 has failed.

Measurement Channel 1 Marker Limit Failed

(bit 2) is set to 1 when any enabled marker limit on measurement channel 1 has failed.

Measurement Channel 2 Marker Limit Failed

(bit 3) is set to 1 when any enabled marker limit on measurement channel 2 has failed.

5-16 Pr ogrammer’s Guide

BISTABLE

LATCH

BISTABLE

LATCH

OUT

BISTABLE

LATCH

OUT

BISTABLE

LATCH

cw61e Fig. 5-6

OUT

CONDITIONS:

Transparent when C (Control) is high (ON). Latched when C (Control) is low (OFF).

CIRCUIT:

BISTABLE LATCH

OUT

Using Status Registers

The Analyzer's Status Register Sets

5-18 Pr ogrammer’s Guide

Using Status Registers

The Analyzer's Status Register Sets

Questionable Status Register Set

The Questionable Status register set monitors conditions that affect the quality of measurement data.

Bits in the Questionable Status condition register are set to 1 under the following conditions:

Limit Fail

(bit 9) is set to 1 when one or more enabled bits in the Limit Fail event register are set to 1.

Data Questionable

(bit 10) is set to 1 when a change in the analyzer's conﬁguration requires that new measurement data be taken.

Programmer’s Guide 5-19

Using Status Registers

The Analyzer's Status Register Sets

Standard Event Status Register Set

The Standard Event Status register set monitors HP-IB errors and synchronization conditions. See Figure 5-7.

Figure 5-7 The Standard Event Status Register Set

The Standard Event Status register set does not conform to the general status register model described at the beginning of this section. It contains only two registers: the Standard Event Status event register and the Standard Event Status enable register. The Standard Event Status event register is similar to other event registers, but behaves like a register set that has a positive transition register with all bits set to 1. The Standard Event Status enable register is the same as other enable registers.

5-20 Pr ogrammer’s Guide

Operation Complete

(bit 0) is set to one when the following two events occur (in the order listed):

1. The *OPC command is sent to the analyzer.

2. The analyzer completes all pending overlapped commands.

Request Control

(bit 1) is set to 1 when both of the following conditions are true:

• The analyzer is conﬁgured as a talker/listener for HP-IB operation.

• The analyzer is instructed to do something (such as plotting or printing) that requires it to take control of the bus.

Query Error

(bit 2) is set when the command parser detects a query error. A query error indicates that one or both of the following actions occurred:

Using Status Registers

The Analyzer's Status Register Sets

• an attempt to read data from the Output Queue when no data was present.

• that data in the Output Queue was lost. An example of this would be queue overﬂow.

Device Dependent Error

(bit 3) is set to 1 when the command parser detects a device-dependent error. A device-dependent error is any analyzer operation that did not execute properly due to some internal condition such as overrange. This bit indicates that the error was not a command, query, or an execution error.

Programmer’s Guide 5-21

Using Status Registers

The Analyzer's Status Register Sets

Execution Error

(bit 4) is set to 1 when the command parser detects an execution error. Execution errors occur when the following conditions occur:

•a<PROGRAM DATA> element received in a command was outside the legal range for the analyzer, or inconsistent with the operation of the analyzer.

• the analyzer could not execute a valid command due to some analyzer condition.

Command Error

(bit 5) is set to 1 when the command parser detects a command error. The following events cause a command error:

• An IEEE 488.2 syntax error occurred. This means that the analyzer received a message that did not follow the syntax deﬁned by the 488.2 standard.

• A semantic error occurred. For example, the analyzer received an incorrectly spelled command. Another example would be that the analyzer received an optional 488.2 command that it does not implement.

User Request

(bit 6) is not implemented. For keypress related functions, see

“Device Status Register Set” on page 5-15.

Power On

(bit 7) is set to 1 when you turn on the analyzer. The commands used to read and write the Standard Event

Status registers are listed below: *ESR? reads the value of the standard event status

*ESE <num> sets bits in the standard event status enable

register. The current setting of the standard event statue enable register is stored in non-volatile memory. If *PSC has been set, it will be saved at power on.

*ESE? reads the current state of the standard event

status enable register.

5-22 Pr ogrammer’s Guide

Using Status Registers

The Analyzer's Status Register Sets

Measuring Status Register Set

The Measuring Status register set monitors conditions in the analyzer's measurement process.

Bits in the Measuring Status condition register are set to 1 under the following conditions:

Channel 1 Measuring (bit 0) is set to 1 while the analyzer is collecting

measurement data on channel 1.

Channel 2 Measuring (bit 1) is set to 1 while the analyzer is collecting

measurement data on channel 2.

Averaging Status Register Set

The Averaging Status register set monitors conditions in the analyzer's measurement process when the trace averaging function is in use.

Bits in the Averaging Status condition register are set to 1 under the following conditions:

Measurement Channel 1 Averaging (bit 0) is set to 1 while the analyzer is sweeping on

measurement channel 1 and the number of sweeps completed (since “average restart”) is less than the averaging factor.

Measurement Channel 2 Averaging (bit 1) is set to 1 while the analyzer is sweeping on

measurement channel 2 and the number of sweeps completed (since “average restart”) is less than the averaging factor.

Programmer’s Guide 5-23

Using Status Registers

The Analyzer's Status Register Sets

Operational Status Register Set

The Operational Status register set monitors conditions in the analyzer's measurement process, disk operations, and printing/plotting operations. It also monitors the state of the current HP Instrument BASIC program.

Bits in the Operational Status condition register are set to 1 under the following conditions:

Calibrating (bit 0) is set to 1 while the instrument is zeroing the

broadband diode detectors.

Settling (bit 1) is set to 1 while the measurement hardware is

settling.

Measuring (bit 4) is set to 1 when one or more enabled bits in the

Measuring Status event register are set to 1.

Correcting (bit 7) is set to 1 while the analyzer is performing a

calibration function.

Averaging (bit 8) is set to 1 when one or more enabled bits in the

Averaging Status event register are set to 1.

Hardcopy Running (bit 9) is set to 1 while the analyzer is performing a

hardcopy (print or plot) function.

Test Running (bit 10) is set to 1 when one of the analyzer's internal

service tests is being run.

Program Running (bit 14) is set to 1 while an HP Instrument BASIC

program is running on the analyzer's internal controller.

5-24 Pr ogrammer’s Guide

The Analyzer's Status Register Sets

Settings for STATus:PRESet

Executing the STATus:PRESet command changes the settings in the enable (ENAB), positive transition (PTR), and negative transition (NTR) registers. The table below shows the settings after the command is executed.

Table 5-1 Status Register States After PRESet Command

STATus:DEVice all 0s all 1s all 0s STATus:QUEStionable:LIMit all 1s all 1s all 0s STATus:QUEStionable all 0s all 1s all 0s STATus:OPERation:MEASuring all 1s all 0s all 1s STATus:OPERation:AVERaging all 1s all 0s all 1s STATus:OPERation all 0s all 1s all 0s

Using Status Registers

Programmer’s Guide 5-25

Using Status Registers

The Analyzer's Status Register Sets

Analyzer Register Set Summary

Figure 5-8 Register Set Summary

5-26 Pr ogrammer’s Guide

6 Trace Data Transfers

6-1

Trace Data Transfers

This chapter explains how to read (query) the measurement data trace from the analyzer into your program. It also describes how to send data from your program to the analyzer's measurement arrays. Accessing the measurement arrays is done using SCPI commands. If you are using IBASIC, you can also access the measurement arrays using high-speed subroutines. Refer to the HP Instrument BASIC User's Handbook for more details.

Figure 6-1 is a data processing ﬂow diagram that represents the ﬂow of

numerical data. The data passes through several math operations, denoted in the ﬁgure by single-line boxes. Most of these operations can be selected and controlled with the front panel CONFIGURE block menus. The data is stored in arrays along the way, denoted by double-line boxes. These arrays are places in the ﬂow path where data is accessible via HP-IB. While only a single ﬂow path is shown, two identical paths are available, corresponding to measurement channels 1 and 2.

Figure 6-1 Numeric Data Flow Through the Network Analyzer

6-2 Pr ogrammer’s Guide

Trace Data Transfers

Querying the Measurement Trace Using BASIC

After making a measurement, you can read the resultant measurement trace out of the analyzer using the SCPI query:

"TRACE:DATA? CH1FDATA"

The BASIC program segment below shows how to read the trace from the analyzer into an array in your program.

10 REAL Trace(1:201) 20 ASSIGN @Hp8711 TO 716 30 ! Take sweep here 40 OUTPUT @Hp8711;"FORM:DATA ASCII,5" 50 OUTPUT @Hp8711;"TRACE:DATA? CH1FDATA" 60 ENTER @Hp8711;Trace(*)

70 DISP Trace(1),Trace(2),Trace(3),"...."

In this program, the TRACE:DATA? query returns all of the measurement points as a single block. The analyzer computes the value for each point using the measurement format selected by the [FORMAT] menu (CALC:FORM SCPI command), and returns a block of data called the formatted data array. The values of each point correspond to the values displayed on the screen, or those shown in the marker readouts. The frequency stimulus value (X-axis) of each point is not returned by the TRACE:DATA? query; only the measurement response (Y -axis) values are returned.

When transferring the block of trace data, you may select either binary or ASCII data encoding. This is explained in Chapter 4, “Data Types and

Encoding,” in the section titled “Data Encoding for Large Data Transfers” on page 4-6. Notice that the terms "encoding format" and

"measurement format" are not the same. The encoding format determines how the numbers are represented as bytes, while the measurement format corresponds to the meaning of the value of the numbers.

The easiest way to transfer a measurement data trace is to use ASCII data encoding.

Programmer’s Guide 6-3

Trace Data Transfers

Querying the Measurement Trace Using BASIC

In the previous above, the array Trace(1:201) contains 201 real (ﬂoating point) numbers. The SCPI command "FORM:DATA ASCII,5" speciﬁes ASCII data encoding, with 5 signiﬁcant digits. The command "TRACE:DATA? CH1FDATA" instructs the analyzer to send the measurement trace. The ENTER statement reads the measurement data sent by the analyzer into the Trace(1:201) array.

It is important to make sure that the Trace array declared in your program is the same size as the measurement trace on the analyzer, or an error will occur. The ENTER statement attempts to read data from the analyzer until it completely ﬁlls the Trace array, at which point it expects to receive an end-of-data terminator from the analyzer. To be safe, your program should use the "SENS:SWE:POIN" SCPI command to set the number of measurement data points to the desired value.

Refer to the example program ASCDATA in the Example Programs Guide for a complete example.

Smith Chart and Polar Formats

Each measurement point is represented by a single ﬂoating point number. This is the case for all of the analyzer's measurement formats except Smith Chart and Polar. When Smith Chart or Polar format is selected, each point is represented by two numbers, the ﬁrst one being the real portion and the second being the imaginary portion of the complex measurement value.

Below is a modiﬁed example program that will work when using Smith Chart or Polar formats.

10 REAL Trace(1:201,1:2) 20 ASSIGN @Hp8711 TO 716 30 ! Take sweep here 40 OUTPUT @Hp8711;"FORM:DATA ASCII,5" 50 OUTPUT @Hp8711;"TRACE:DATA? CH1FDATA" 60 ENTER @Hp8711;Trace(*)

70 DISP Trace(1,1),Trace(1,2),". . . .",Trace(201,1),Trace(201,

6-4 Pr ogrammer’s Guide

Trace Data Transfers

Querying the Measurement Trace Using SICL

This section includes a complete SICL C program that shows how to read the measurement trace from the analyzer.

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

* This program takes a sweep, reads the trace, and prints it. * It uses SICL (Standard Instrument Control Library) to talk * to the analyzer over HP-IB. * * On HP-UX, compile using: cc -Aa -o query_trace query_trace.c -lsicl

**************************************************************************/ #include <sicl.h> /* For iopen(), iprintf(), iscanf(), INST, ... */ #include <stdio.h> /* For printf() */

int main(void) {

INST analyzer; /* Handle used to talk to analyzer */ float data_buf[1601]; /* measurement trace. 32-bit floats */ int num_trace_bytes; int pt; num_trace_bytes = sizeof(data_buf); /* Set to max allowable bytes */

/* Open the network analyzer at address 16 */ analyzer = iopen("hpib,16");

/* Clear the bus */ iclear(analyzer);

/* Abort current sweep and put analyzer sweep in hold */ iprintf(analyzer, "ABORT\n"); iprintf(analyzer, "INIT:CONT OFF\n");

/* Take one sweep, wait until done */ iprintf(analyzer, "INIT1\n"); iprintf(analyzer, "*OPC?\n"); iscanf(analyzer, "%*s");

/* Request the trace data in 32-bit floating point format */ iprintf(analyzer, "FORM:BORD NORM\n"); iprintf(analyzer, "FORM:DATA REAL,32\n");

/* Query the trace, read into data_buf[]. */ iprintf(analyzer, "TRAC? CH1FDATA\n"); iscanf(analyzer, "%#b%*c", &num_trace_bytes, &data_buf[0]);

/* Print the trace values. */ for (pt = 0; pt < num_trace_bytes/sizeof(float); pt++) {

printf("%4d %g\n", pt, data_buf[pt]); } /* Close analyzer and exit. */ iclose(analyzer); return 0;

}

Programmer’s Guide 6-5

Trace Data Transfers

Using Binary Data Encoding

The previous section describes how to query the measurement trace, and transfer it into your program using ASCII encoding. Binary encoding can be used for faster data transfers, as shown in the table below:

Table 6-1 Trace Transfer Times (typical)

Number of Trace

Points

51 21 47 201 23 164 401 30 314

1601 82 1200

When using binary data transfers, the entire trace is sent from the analyzer to your program in a block called a deﬁnite length block. The details of block data are described in detail in Chapter 4, “Data Types

and Encoding.” The deﬁnite length block contains a header and a data

section. The header indicates how many bytes are in the data section. In order to read the deﬁnite length block, your program must ﬁrst read

the header , and then read the data section. Refer to the example program REALDATA in theExample Programs Guide for an example of how to do this.

In the REALDATA program, you will notice the following lines which read the deﬁnite block header:

180 ENTER @Hp8711 USING "%,A,D";A$,Digits 190 ENTER @Hp8711 USING "%,"&VAL$(Digits)&"D";Bytes

and these lines which read the data section:

200 ASSIGN @Hp8711;FORMAT OFF 210 ENTER @Hp8711;Data1(*)

Transfer Times (ms)

Binary

Transfer

ASCII

Transfer

6-6 Pr ogrammer’s Guide

Trace Data Transfers

Using Binary Data Encoding

Each measurement point in the data section is represented as 4 or 8 bytes (32 or 64 bits), depending on whether single precision or double precision numbers are requested. When using HP BASIC or IBASIC , you must select double precision numbers to match BASIC's "REAL" data type. Do this using the SCPI command "FORM:DATA REAL,64". If you are using another language that supports single precision data types, you can select single precision using the SCPI command "FORM:DATA REAL,32". Languages such as QuickBASIC and C have support for both single and double precision ﬂoating point numbers.

When transferring data using binary encoding, you may need to reverse the order of the bytes in each measurement point, since PCs frequently store IEEE ﬂoating point numbers with the byte order reversed. To instruct the analyzer to reverse the byte order of the data, send the command "FORMAT:BORDer SWAPped" before querying the trace data.

Programmer’s Guide 6-7

Trace Data Transfers

Using Binary Data Encoding

Trace Data Transfer Sizes

The following table shows how many bytes are transmitted during trace data transfers. The left column shows the format of the data, which you can specify using the SCPI command Format:DATA. As you can see, the size of the measurement point data and trace data varies as you change format.

Table 6-2 Trace Data Transfer Size Using TRACE:DATA Command

Format Type

(FORMat:DATA)

REAL,32 IEEE 32-bit

REAL,64 IEEE 64-bit

ASCII,5 ASCII

ASCII,3 ASCII

INT,16 Internal

When transmitting data in "REAL" or "INT" format, a header is sent before the data block. The header indicates the size of the data block. The header size varies in length from 3 to 11 bytes. Refer to Chapter 4, “Data

Types and Encoding,” for details on the header.

Type of

Data

Floating Point

numbers

Binary

Size of Single

Measurement Point

(bytes)

Real Complex Real Complex

4 8 809 1614

8 16 1614 3222

13 26 2613 5226

11 22 2211 4422

— 8 — 1614

Size of 201 Point

Trace

(bytes)

Transmitting ASCII data requires no header. The ASCII values are separated by commas, and a linefeed is sent after the last value. The sizes shown in the table include the size of the comma(s) and terminating linefeed. Typical data in ASCII,5 format:

-1.2254E+000,+5.0035E-001,+4.5226E-001,...

6-8 Pr ogrammer’s Guide

Trace Data Transfers

Using Binary Data Encoding

The analyzer stores its internal data with approximately 5 signiﬁcant digits of resolution. Using REAL,32 or ASCII,5 format provides sufﬁcient precision for data transfers. However, REAL,64 may be necessary when using a programming language which does not support IEEE 32-bit ﬂoating point.

Programmer’s Guide 6-9

Trace Data Transfers

Transferring Data with IBASIC

If you are using IBASIC, your IB ASIC program can avoid the overhead of using OUTPUT and ENTER to transfer trace data, and instead use the analyzer's built-in high-speed subprograms. These built-in subroutines let you quickly move data between the analyzer's measurement arrays and your program's data arrays. For example, to read the analyzer's formatted data array, use the following:

10 DIM Fmt(1:201) 20 INTEGER Chan 30 LOADSUB Read_fdata FROM "XFER:MEM 0,0" 40 Chan=1 50 Read_fdata(Chan,Fmt(*))

Refer to the HP Instrument BASIC User's Handbook for more details. The table below compares the speed of IBASIC using high-speed transfer

subroutines with that of a fast external controller using the SCPI TRACE:DATA? CH1FDATA query.

Table 6-3 High-Speed Trace Transfer Times

Number of Trace P oints

51 21 7 201 23 10 401 30 13

1601 82 32

6-10 Pr ogrammer’s Guide

Controller Using Binary

TRACE:DATA?

(ms)

IBASIC Using

Read_fdata

(ms)

Trace Data Transfers

Taking Sweeps

When making measurements and querying traces, your program should perform the following steps:

1. Place the analyzer's sweep in hold.

2. Initiate a single sweep.

3. Wait for the sweep to complete.

4. Query the measurement trace. Use the following program lines to perform these steps:

10 OUTPUT @Hp8711;"ABORT;:INIT1:CONT OFF" 20 OUTPUT @Hp8711;"INIT1" 30 OUTPUT @Hp8711;"*OPC?" 35 ENTER @Hp8711;Opc 40 OUTPUT @Hp8711;"TRACE:DATA? CH1FDATA" 45 ENTER @Hp8711;Fmt(*)

If you query the measurement trace while the analyzer is in continuous sweep, the query will still work, but the data may not be correct. Using INIT and *OPC? ensures that a complete sweep has ﬁnished before you query the measurement data. In many cases, you can also use the command "*WAI" in place of the "*OPC?" query, replacing lines 30 and 35 above with:

30 OUTPUT @Hp8711;"*WAI"

However, there are cases where "*WAI" will produce incorrect results. One case is when using IBASIC's high-speed subprograms to query the trace data. "*WAI" only ensures that the SCPI commands following the "*WAI" are not executed until the commands before the "*WAI" are complete. Since IBASIC subprograms don't use SCPI commands to access the trace data, "*WAI" is ineffective, and "*OPC?" should be used.

When using "*OPC?", the ENTER statement following the "*OPC?" will wait until the previous SCPI commands are complete, preventing your program from executing beyond the ENTER statement. When using "*WAI", your program can continue to run and send SCPI commands, and the analyzer will buffer them and act upon them in order.

Chapter 2, “Synchronizing the Analyzer and a Controller,” provides

additional details.

Programmer’s Guide 6-11

Trace Data Transfers

CALC:DATA? versus TRACE:DATA?

The SCPI command "CALC1:DATA?" is functionally equivalent to the command "TRACE:DATA? CH1FDATA". The two can be used interchangeably for trace queries of the formatted measurement data. The "TRACE:DATA" command is more ﬂexible, allowing you to query other measurement arrays and to download data to measurement arrays.

6-12 Pr ogrammer’s Guide

Trace Data Transfers

Querying Single Data Points Using Markers

If you only need to query a single data point, you can use a marker query instead of a trace query. The program segment below shows how to do this using the SCPI command CALC:MARK.

10 ASSIGN @Hp8711 TO 716 20 ! Take sweep here 30 OUTPUT @Hp8711;"CALC1:MARK ON" ! turn on marker 40 OUTPUT @Hp8711;"CALC1:MARK1:X 177 MHz" ! set frequency 50 OUTPUT @Hp8711;"CALC1:MARK1:Y?" ! read marker 60 ENTER @Hp8711;Marker_y 70 DISP Marker_y

You can also use the CALC:MARK:FUNC:RES? query to return the results of a bandwidth search. The following program steps accomplish these tasks:

10 ! Select -3 dB bandwidth 20 OUTPUT @Hp8711;"CALC:MARK:BWID -3" 30 ! Get result of bandwidth search 40 OUTPUT @Hp8711;"CALC:MARK:FUNC:RES?" 50 ENTER @Hp8711;Bwidth,Center_freq,Q,Loss

For more information on using markers, refer to the Example Programs Guide.

Programmer’s Guide 6-13

Trace Data Transfers

Accessing Other Measurement Arrays

The preceding sections describe how to query the formatted data array using the TRACE:DATA? query with the argument CH1FDATA. The formatted array is the last array in the analyzer's data processing chain, and is generally of most interest.

The analyzer also allows you to query other measurement arrays which are earlier in its data processing chain. Figure 6-2 shows the data processing chain.

Figure 6-2 Numeric Data Flow Through the Network Analyzer

The ﬁrst array is the Raw Data Array, which contains each of the separate input components (A, B, R, B*, R*, X, Y, AUX) immediately after they are measured. These arrays can be queried and set, but doing so is of limited use, since the data values contained in the arrays are uncorrected, and are not directly correlated to any meaningful reference, such as 0 dBm.

6-14 Pr ogrammer’s Guide

Trace Data Transfers

Accessing Other Measurement Arrays

The Error Coefﬁcient arrays contain default correction values or values created during a measurement calibration. These arrays can be queried and set, but care should be exercised in setting them since incorrect measurements may result. If you wish to apply your own corrections in addition to the analyzer's current correction, the best technique is to use the Corrected Memory array and the Data/Memory feature, explained below.

The Corrected Data array contains the results of the currently selected measurement (Transmission, Reﬂection, etc.) after error correction and averaging have been applied. The measurement data in these arrays is represented as complex number pairs. When measuring the transmission response of a through cable, the magnitude of the complex numbers will be very close to 1.0. When measuring an open circuit, the magnitude of the complex numbers will be very close to 0.0. When measuring an ampliﬁer, the magnitude of the complex numbers will be greater than 1.0.

The Corrected Memory array is ﬁlled with a copy of the Corrected Data array when the Data −> Memory operation is performed. It can be used to apply a gain correction to the measured data. This is described in the following section.

The Formatted Data array contains the measurement data after it has been formatted using the format selected by the [FORMAT] menu. Querying the Formatted Data array is described in detail at the beginning of this chapter. You can also download data to this array, and the analyzer will display the data using the current Scale and Reference values.

Programmer’s Guide 6-15

Trace Data Transfers

Applying Gain Correction Using the Memory Trace

The Corrected Memory array is ﬁlled with a copy of the Corrected Data array when the Data −> Memory operation is performed. By setting the analyzer to perform Data/Memory trace math, you can apply your own correction factor to the measurement data trace by ﬁlling the Corrected Memory array with the appropriate complex numbers.

In general, you should use the analyzer's calibration feature to correct for errors in your system. However , there ma y be cases where you wish to simulate the effect of adding a cable in series with your DUT, and observe how this imaginary cable will attenuate the measured response versus frequency. Or you may wish to apply an absolute offset to simulate the effect of adding or removing a pad from the measurement. These simulations are easily accomplished using the Corrected Memory array and the Data/Memory feature.

The Corrected Data and Memory arrays contain complex linear data, as opposed to logged data. When displaying the traces using Lin Mag format, the result of the Data divided by Memory operation (Data/Mem) will be to divide each point of the data trace by each point of the memory trace. When displaying data in Log Mag format, the result of Data/Memory will be equivalent to subtracting the Log Mag value of the Memory trace from that of the Data trace.

6-16 Pr ogrammer’s Guide

Trace Data Transfers

Applying Gain Correction Using the Memory Trace

The following example BASIC code segment shows how to download a complex array from your program to the analyzer's Memory trace. The program's "Mem" array is initialized with the proper values such that when the analyzer computes Data divided by Memory, the desired increasing gain will be applied.

100 REAL Mem(1:201,1:2) 110 ASSIGN @Hp8711 TO 716 120 ! Fill memory array (denominator in Data/Mem) 130 ! with values that will result in an 140 ! upward sloping gain factor vs. frequency. 150 ! Used to compensate for cable loss vs. frequency 160 ! Adds 0 dB of gain at start freq; 3 dB at stop freq 170 FOR Pt=1 TO 201 180 Gain_factor_db=3.0*(Pt − 1)/200 ! 0..3 dB Power 190 Gain_factor_lin=10^(Gain_factor_db/20) 200 Mem(Pt,1)=1.0/Gain_factor_lin ! real 210 Mem(Pt,2)=0.0 ! imag 220 NEXT Pt 230 ! Download to the memory trace 240 OUTPUT @Hp8711;"FORM:DATA ASCII" 250 OUTPUT @Hp8711;"TRACE:DATA CH1SMEM"; ! Note the ";" 260 FOR Pt=1 TO 201 270 FOR I=1 TO 2 280 OUTPUT @Hp8711;",";Mem(Pt,I); ! Note the ";" 290 NEXT I 300 NEXT Pt 310 OUTPUT @Hp8711;"" ! Send linefeed 320 OUTPUT @Hp8711;"CALC1:MATH (IMPL/CH1SMEM)" ! Data/Mem

The example above downloads data to the corrected memory array. The data is sent by the program to the analyzer using ASCII encoding. The data is sent as ASCII characters, separated by commas. The analyzer accepts the comma separated list of numbers until it receives a linefeed to terminate the command. The program uses semicolons at the end of some OUTPUT statements to avoid sending a linefeed until all of the data has been sent. After the last number is sent, the program sends a linefeed, and the analyzer accepts the data.

Remember, for faster transfers, use binary data encoding instead of ASCII.

Programmer’s Guide 6-17

Trace Data Transfers

Performing Your Own Data Processing

After the analyzer has made a measurement, you can read the measurement trace and perform your own post-processing on it, and display the result on the screen. This is done using these steps:

1. Initiate a sweep.

2. Wait for the sweep to ﬁnish.

3. Read the measurement data into an array in your program.

4. Perform your post-processing on the measurement data.

5. Write (download) the post-processed data to the analyzer's memory trace.

You may want to instruct the analyzer to display only the memory trace and not the data trace, so that only your post-processed data is seen.

6-18 Pr ogrammer’s Guide

Trace Data Transfers

Performing Your Own Data Processing

The program below demonstrates how to perform data post-processing. It takes the measurement data and reverses it, such that the low frequency data is displayed on the right end of the trace, and the high frequency data is displayed on the left.

100 ! Display the measurement data backwards 110 REAL Fmt(1:201) 120 ASSIGN @Hp8711 TO 716 130 ! 140 OUTPUT @Hp8711;"FORM:DATA ASCII" 150 OUTPUT @Hp8711;"ABOR;INIT:CONT OFF;*WAI" 160 OUTPUT @Hp8711;"DISP:WIND:TRAC1 OFF;TRAC2 ON" 170 LOOP 180 ! Take sweep 190 OUTPUT @Hp8711;"INIT1;*WAI" 200 ! Read the trace from the formatted data array 210 OUTPUT @Hp8711;"TRACE:DATA? CH1FDATA" 220 ENTER @Hp8711;Fmt(*) 230 ! Download the trace, backwards, 235 ! to the formatted memory array 240 OUTPUT @Hp8711;"TRACE:DATA CH1FMEM"; ! Note the ";" 250 FOR Pt=1 TO 201 260 OUTPUT @Hp8711;",";Fmt(202-Pt); ! Note the ";" 270 NEXT Pt 280 OUTPUT @Hp8711;"" ! Send linefeed 290 END LOOP

This example program uses ASCII trace data transfers. Higher speed can be achieved using binary data transfers. If using IBASIC , high-speed subroutines can be used for even greater performance. Refer to the IBASIC Handbook for details.

Programmer’s Guide 6-19

Trace Data Transfers

Downloading Trace Data Using Binary Encoding

Data traces can be downloaded to the analyzer using binary encoding. Using binary encoding is faster than using ASCII encoding. As mentioned in “Using Binary Data Encoding” on page 6-6, the binary encoded trace is transferred as a block; the block contains a header and a data section. There are two different types of blocks that can be used: a deﬁnite length block, and an indeﬁnite length block.

To send trace data using a deﬁnite length block, your program must calculate the number of bytes in the data segment of the block, and create a block header which tells the analyzer how many bytes are in the data segment.

For example, if you are sending a trace with 201 data points and using 64-bit ﬂoating point numbers for each data point (FORM:DATA REAL,64), the block's data segment will contain 1608 bytes (201 points * 8 bytes/point). The header characters for a 1608 byte block are: "#41608". The ﬁrst digit after the "#", "4" tells how many following digits are used to specify the size. In this case, 4 digits follow, and those digits are "1608", meaning that the block contains 1608 bytes.

When you send a deﬁnite length block to the analyzer, the analyzer will read the data segment bytes, stopping when it receives the number speciﬁed in the block header.

To send trace data using an indeﬁnite length block, your program sends a block header of "#0", followed by the data segment. After sending the data segment, your program must terminate the data block by sending an EOI. The analyzer will read the data segment bytes, stopping when it receives an EOI. To send an EOI using BASIC, you can use the statement:

OUTPUT @Hp8711;END

6-20 Pr ogrammer’s Guide

Internal Measurement Arrays

The following sections describe the sequence of math operations and the resulting data arrays as the measurement information ﬂows from the raw data arrays to the display. This information explains the measurement arrays accessible via HP-IB.

Figure 6-3 is a data processing ﬂow diagram that represents the ﬂow of

Figure 6-3 Numeric Data Flow Through the Network Analyzer

Trace Data Transfers

Programmer’s Guide 6-21

Trace Data Transfers

Internal Measurement Arrays

Raw Data Arrays

These arrays are linear measurements of the inputs used in the selected measurement. Note that these are pairs of complex numbers. The arrays are directly accessible via HP-IB and are referenced as CH[1|2]AFWD, CH[1|2]BFWD and CH[1|2]RFWD. Raw data for AUX INPUT is not available via HP-IB. Use the corrected data array to access AUX INPUT data.

Table 6-4 Raw Data Arrays

Selected Measurement Raw Arrays

Ratio Calculations

These are performed if the selected measurement is a ratio (e.g. A/R or B/R). This is simply a complex divide operation. If the selected measurement is absolute (e.g. A or B), no operation is performed.

6-22 Pr ogrammer’s Guide

Error Correction

Error correction is performed next if correction is turned on. Error correction removes repeatable systematic errors (stored in the error coefﬁcient arrays) from the raw arrays. The operations performed depend on the selected measurement type.

Error Coefﬁcient Arrays

The error coefﬁcient arrays are either default values or are created during a measurement calibration. These are used whenever correction is on. They contain complex number pairs, are accessible via HP-IB, and are referenced as CH[1|2]SCORR1, CH[1|2]SCORR2, CH[1|2]SCORR3 and CH[1|2]SCORR4.

Table 6-5 Error Coefﬁcient Arrays

Selected Measurement Error Coefﬁcient Arrays

Transmission (B/R) Response CH[1|2]SCORR1 Tracking Transmission (B/R) Response & Isolation CH[1|2]SCORR1 Tracking

Trace Data Transfers

Internal Measurement Arrays

CH[1|2]SCORR2 Isolation Term

Transmission (B/R) Enhanced Response CH[1|2]SCORR1 Directivity

CH[1|2]SCORR2 Source Match CH[1|2]SCORR3 Reﬂection Tracking CH[1|2]SCORR4 Transmission Tracking

Reﬂection (A/R) CH[1|2]SCORR1 Directivity

CH[1|2]SCORR2 Source Match CH[1|2]SCORR3 Tracking

Broadband Internal CH[1|2]SCORR1 R* Response

NOTE These arrays do not apply to Broadband External measurements.

Programmer’s Guide 6-23

Trace Data Transfers

Internal Measurement Arrays

Table 6-6 2-Port Error Coefﬁcient Arrays

Direction Error Coefﬁcient Arrays

Forward CH[1|2]SCORR1 Directivity

Reverse CH[1|2]SCORR7 Directivity

6-24 Pr ogrammer’s Guide

Trace Data Transfers

Internal Measurement Arrays

Averaging

Averaging is a noise reduction technique. This calculation involves taking the complex exponential average of several consecutive sweeps. This averaging calculation is different than the System Bandwidth setting. System Bandwidth uses digital ﬁltering, applying noise reduction to the measured data before it is stored into the Raw Data Arrays.

Corrected Data Arrays

The combined results of the ratio, error correction and averaging operations are stored in the corrected data arrays as complex number pairs. These arrays are accessible via HP-IB and referenced as CH[1|2]SDATA.

Corrected Memory Arrays

If the Data−>Mem or Normalize operations are performed, the corrected data arrays are copied into the corrected memory arrays. These arrays are accessible via HP-IB and referenced as CH[1|2]SMEM.

Programmer’s Guide 6-25

Trace Data Transfers

Internal Measurement Arrays

Trace Math Operation

This selects either the corrected data array, or the corrected memory array, or both to continue ﬂowing through the data processing path. In addition, the complex ratio of the two (Data/Memory) can also be selected. If memory is displayed, the data from the memory arrays goes through exactly the same data processing ﬂow path as the data from the data arrays.

Electrical Delay

This block adds or subtracts phase, based on the settings of Phase Offset, Electrical Delay, and Port Extension. The Electrical Delay and Port Extension features add or subtract phase in proportion to frequency. This is equivalent to "line stretching" or artiﬁcially moving the measurement reference plane. (See your analyzer’s User Guide for more details on these features.)

Transform (Option 100 only)

This block converts frequency domain data into distance domain, or into an SRL impedance value when measuring fault location or SRL. The transform employs an inverse fast Fourier transform (FFT) algorithm to accomplish the conversion.

Formatting

This converts the complex number pairs into a scalar representation for display, according to the selected format (e.g. Log Mag, SWR, etc). These formats are often easier to interpret than the complex number representation. Note that after formatting, it is impossible to recover the complex data.

Formatted Arrays

The results so far are stored in the formatted data and formatted memory arrays. It is important to note that marker values and marker functions are all derived from the formatted arrays. Limit testing is also performed on the formatted arrays. These arrays are accessible via HP-IB and referenced as CH[1|2]FDATA and CH[1|2]FMEM.

6-26 Pr ogrammer’s Guide

Agilent 8712ES Programmer’s Guide

Specifications and Main Features

Frequently Asked Questions

User Manual

Introduction to HP-IB Programming

Bus Structure

Data Bus

Handshake Lines

Control Lines

Sending Commands

HP-IB Requirements

Interface Capabilities

Programming Fundamentals

Controller Capabilities

Response to Bus Management Commands

Message Exchange

Synchronizing the Analyzer and a Controller

Overlapped Commands

Controlling Execution of Overlapped Commands

Using *WAI and *OPC?

3 Passing Control

Passing Control

4 Data Types and Encoding

Data Types and Encoding

Data Types

Numeric Data

Character Data

String Data

Expression Data

Block Data

Data Encoding for Large Data Transfers

ASCII Encoding

Binary Encoding

Byte Swapping

5 Using Status Registers

Using Status Registers

General Status Register Model

Condition Register

Transition Registers

Event Register

Enable Register

How to Use Registers

The Service Request Process

Generating a Service Request

The Analyzer's Status Register Sets

Status Byte

Device Status Register Set

Limit Fail Register Set

Questionable Status Register Set

Standard Event Status Register Set

Measuring Status Register Set

Averaging Status Register Set

Operational Status Register Set

Settings for STATus:PRESet

Analyzer Register Set Summary

6 Trace Data Transfers

Trace Data Transfers

Querying the Measurement Trace Using BASIC

Smith Chart and Polar Formats

Querying the Measurement Trace Using SICL

Using Binary Data Encoding

Trace Data Transfer Sizes

Transferring Data with IBASIC

Taking Sweeps

CALC:DATA? versus TRACE:DATA?

Querying Single Data Points Using Markers

Accessing Other Measurement Arrays

Applying Gain Correction Using the Memory Trace

Performing Your Own Data Processing

Downloading Trace Data Using Binary Encoding

Internal Measurement Arrays

Raw Data Arrays

Ratio Calculations

Error Correction

Averaging

Corrected Data Arrays

Corrected Memory Arrays

Trace Math Operation

Electrical Delay

Transform (Option 100 only)

Using WAI and OPC?