Table of Contents

Previous Chapter

Next Chapter

2.0 GSE Transport Tools

These components occupy the top third of Figure 2, except that buildCmds is a "GSE Test Tool". The ACIS instrument is represented by the box at the top left. It may communicate through as many as 3 simultaneous interfaces, the RCTU/CTUE, representing the interface that will be used at XRCF and closely parallels the AXAF spacecraft interface itself; the LRCTU which is a simplified replacement for the RCTU/CTUE developed at MIT; the "High Speed Tap" which amples the digital image pixels being output from one of the ACIS analog boards; and the "Image Loader", an MIT-developed hardware interface that mimics the analog boards and permits test images to be sent directly to one or more FEP boards.

The software consists of the server-client pairs, their input and output interface, and their protocols. There are five GSE Transport programs: shim, sendCmds, getPackets, filterServer and filterClient. All are being developed by ACIS EGSE personnel, with assistance from the ACIS Flight Software Team.

2.1 sendCmds

sendCmds receives a binary command stream from buildCmds, containing type, channel, data triplets. It constructs 23-bit, formatted command strings, packages them into 24-bit strings to simplify the output interface, and sends them to shim. This command is described in detail in Section 10.29.

2.2 cclient

cclient makes a TCP connection to a socket previously created by the cserver program. Once the connection has been established, cclient copies its standard input to the socket. When it encounters an end-of-file condition on stdin, it closes the socket and exits. Its function is therefore to isolate the commands generated by sendCmds and buildCmds from shim and ACIS itself-a series of commands can be issued from separate UNIX processes, even from different host computers, and cserver will merge them into a single unbroken command stream. This command is described in detail in Section 10.7.

2.3 cserver

cserver creates a socket and listens for connections from cclient processes. When one is made, it copies the contents of the socket to its standard output, stdout. On an end-of-socket or error condition, cserver closes the connection and waits for another one. This command is described in detail in Section 10.8.

2.4 shim

shim provides a consistent interface between ACIS and all user applications that generate commands or receive telemetry. It can communicate with ACIS either through the LRCTU (RCTU/CTUE emulator) or through the RCTU/CTUE itself. This command is described in detail in Section 10.30

When sending commands to an LRCTU, shim drops all High Level Pulse commands because the LRCTU does not support them. It passes all other Serial Digital Hardware and Software commands to the LRCTU via a serial interface in the 24 bit format generated by sendCmds. When receiving telemetry from an LRCTU via the same serial interface, shim formats the packets into AXAF-I telemetry major frames, adding science frame headers and ACIS and IRIG-B timestamps as appropriate.

When shim sends commands to an RCTU/CTUE, it includes High Level Pulse commands as well as Serial Digital Hardware and Software commands. It extracts the 23-bit input command words from the 24 bit sendCmds format and packs them into 48-bit Ground Command Format strings. It then assembles these strings into command blocks, which it sends to the RCTU/CTUE via a TCP/IP interface. It receives telemetry via the same interface and passes them to its client (getPackets unmodified.

2.5 getPackets

getPackets receives AXAF-I telemetry frames from shim. It extracts ACIS-related information and passes it to its filterServer client. It must first identify the current telemetry format--either 1 or 2. In the former, ACIS science data is being generated at 512 bits/sec; in the latter at 24 Kbits/sec. In both cases,getPackets assembles the serial telemetry from ACIS, locates the individual packets by their synch words and lengths, and writes them to filterServer as separate logical records.

getPackets also sends filterServer two types of "pseudo-packet", i.e. records whose format mimics genuine ACIS telemetry packets but whose "type" codes are distinguished from those used by the instrument itself. One type of pseudo-packet contains data from science frame headers and from ACIS timestamps. The other contains ACIS and other AXAF engineering data that was found in the non-science areas of the telemetry frames. This command is described in detail in Section 10.17

2.6 filterServer

filterServerreceives the stream of telemetry packets from stdin and listens on an INET socket for network clients to request TCP connections. When this occurs,filterServer determines the data types requested by the client, and then forks a copy of itself to write those packets to the client. Clients connecting to filterServer send it a short message that indicates which of the 4 types of telemetry they wish to receive. filterServer writes all telemetry packets of the requested types to the output socket.

If filterServer doesn't understand the data request, it closes the INET socket and writes an error message to stderr. Once a connection is made, the packet type cannot be changed. When a client no longer wants packets, it closes the socket--the spawned server process should exit after logging the event to stderr. This command is described in detail in Section 10.14

2.7 filterClient

filterClient inspects its argument list to determine the location (host and port number) of a filterServer process, and which types of packet it is to request. It establishes a TCP connection to the server, sends a request for data, and copies the resulting stream to stdout. This command is described in detail in Section 10.13

2.8 Transport Tool Interfaces

The major external interfaces are between buildCmds and sendCmds, and between getPackets and its various clients (via the filterServer/filterClient combination). Both interfaces may be described as a single stream of binary bytes, with no timing constraints.

2.8.1 Stdin to sendCmds

sendCmds expects its standard input to consist of pairs of 16-bit words (command type and channel) followed by one or more 16-bit words--the command packet, as described in Table 1. All 16-bit words are assumed to start with their least significant bytes, i.e. little-endian order.

The format and content of command packets are contained in the AXAF IP&CL documents. All packets contain length fields which are extracted by sendCmds to determine how to read the remainder of the command packet.

High Level Pulse Commands are completely specified by the Command Type and Command Channel pair. Therefore, no command data will follow.

Serial Digital Hardware Commands will consist of a single 16-bit word that will immediately follow the Command Type and Command Channel pair.

Serial Digital Software Commands will consist of from 3 to 256 16-bit words contained in an ACIS software command packet that will immediately follow the Command Type and Command Channel pair. All software command packets contain length fields which are extracted by sendCmds to determine how to read the remainder of the command packet. The output, which is produced in 3-byte groups, is described in Table 2.

¹ bit 0 is the most significant bit and is transmitted/received first.

When sendCmds reads an illegal command type or command channel from stdin, it writes an error message to stderr and terminates processing. When sendCmds reads an illegal software command packet from stdin, it writes an error message to stderr and continues processing the next command from stdin.

The location of shim will be specified via command-line arguments. Commands will be passed to shim as soon as the last 16-bit word is read from stdin. Since this is buffered via the stdio.h library, it is the responsibility of a program piping commands to sendCmds to flush the pipe, e.g. with a call to fflush(), before any planned inter-command delay. Otherwise, the time delay will be unpredictable.

When sendCmds reads an illegal packet from stdin, it writes an error message to stderr. Depending on arguments supplied on its command line, sendCmds may then decide to continue processing the next command from stdin, or abort the run entirely.

2.8.2 Stdout from filterClient

getPackets writes a stream of telemetry packets and pseudo-packets to stdout, These are passed through filterServer to each filterClient, which writes a user-selected sub-set to its stdout. The four packet types that may be selected are: "ACIS Science Packets", "ACIS Analog Housekeeping Packets", "Science-Frame Pseudo-Packets", and "Engineering Pseudo-Packets". Each packet consists of a telemetry header followed by application data, as defined in IP&CL. The header formats and contents are defined in Table 3.

¹ The packet length (number of 32 bit words) varies with the contents.
² The sequence number of a pseudo-packet is always zero.

All fields are written in "little-endian" format, e.g. the packet synch word, 0x736f4166, is written as 4 bytes, 0x66, 0x41, 0x6f, and finally 0x73. The contents of all packets originating within ACIS are defined in IP&CL. The data portion of the Science Frame pseudo-packet is described in Table 4 and that of the Engineering pseudo-packet in Table 5.

The 6-byte IRIG-B timestamp in the AXAF-I minor frame is the result of packing 4 separate bit fields into a 48-bit string. However, getPackets treats the 6 bytes of the IRIG-B timestamp as 3 unsigned 16-bit integers. It copies them into the Engineering Pseudo-Packet and converts them to little-endian format, which is the ACIS standard. Table 6 describes how to decipher the Engineering Pseudo-Packet's irigb field.

Each packet will be written to the getPackets standard output stream as soon as the last data byte that contributes to it is read from shim. A Science Frame Pseudo-Packet will be written after reading the last byte of each complete minor frame containing a science frame header. An Engineering Pseudo-Packet will be written after the last byte of each complete major frame is read.

2.8.3 filterClient arguments

The content of filterClient's stdout stream and the location and port number of the filterServer are selected by UNIX runtime arguments, as described inSection 10.13 and Section 10.14. The telemetry packet selections will be determined by the presence of one or more of the mnemonics listed in Table 7.

3.0 GSE Test Tools

These consist of two groups of UNIX commands--primitive programs that translate between binary ACIS representations (commands and telemetry packets) and their human-readable ASCII equivalents; and analysis programs that perform various higher-level functions. All programs are being developed by the ACIS flight software team, except were noted.

3.1 buildCmds

This program, described in detail in Section 10.6, reads an ASCII command script from stdin and writes a binary command stream to stdout. The binary output format is described in "Stdin to sendCmds".

Each ACIS command must appear on a separate input line. The only exception is that in-line param_blocks may contain newline characters within the enclosing braces. The full list of buildCmds commands are shown in Table 8, Table 9, and Table 10.

¹ all ACIS Software Serial Commands are assigned the mnemonic 1SWSDICL in the AXAF IP&CL tables.

¹ command mnemonics are defined in the AXAF IP&CL tables.
² EEPROM commands cannot be executed on flight hardware after SI integration.

¹ the id field represents the hardware redundancy, either 0 for the A-side or 1 for the B-side.
² command mnemonics are defined by AXAF IP&CL tables. `*' represents the hardware redundancy, either `A' or `B'.

3.1.1 buildCmds Examples

• The following UNIX pipe commands the ACIS instrument to start executing stored timed exposure parameter block 1:

  echo `start 22 te 1' | buildCmds | sendCmds

• Dump 600 words from FEP number 2, starting at word offset 45678. Give this command the identifier `4'.

  echo read 4 fep 2 45678 600 | buildCmds | sendCmds

• Start a timed exposure using the parameter block in slot #2. Give this command the identifier `11'.

  echo start 11 te 2 | buildCmds | sendCmds

• Stop a Science run. Give this command the identifier `5'.

  echo stop 5 science | buildCmds | sendCmds

• Load a 2-dimensional window block. The order of keywords within each window structure is significant--if a keyword is omitted, the most recent value will be used (zero if it has not yet been used within the block).

  load 33 window1D 4 {
    parameterBlockName  = window1D
    windowBlockId       = 45
    arrayDim            = 3       < number of structures to follow
  
    ccdId               = 1       < first window structure
    ccdColumn           = 2
    width               = 4
    sampleCycle         = 6
    lowerEventAmplitude = 7
    eventAmplitudeRange = 8
  
    ccdId               = 2       < second window structure
    ccdColumn           = 3
    width               = 6
    sampleCycle         = 8
    lowerEventAmplitude = 10
    eventAmplitudeRange = 20
  
    ccdId               = 3       < third window structure
    ccdColumn           = 20
    width               = 40
    sampleCycle         = 2
    lowerEventAmplitude = 70
    eventAmplitudeRange = 80
  }
  	      

• Load a Continuous Clocking parameter block. The parameter block is to be stored in slot #3 and the command is given the identifier `22'. The keywords must appear in the order shown. If omitted, a zero value will be assumed.

  load 22 cc 3 {
    paramBlockName          = ccBlock
    parameterBlockId        = 2030
    fepCcdSelect            = 0 1 2 3 4 5
    fepMode                 = 1
    bepPackingMode          = 1
    ignoreBadColumnMap      = 0
    recomputeBias           = 1
    trickleBias             = 1
    rowSum                  = 4
    columnSum               = 5
    overclockPairsPerNode   = 8
    outputRegisterMode      = 2
    ccdVideoResponse        = 1 1 1 1 1 1
    fep0EventThreshold      = 100 100 100 100
    fep0EventThreshold      = 100 100 100 100
    fep0EventThreshold      = 100 100 100 100
    fep0EventThreshold      = 100 100 100 100
    fep0EventThreshold      = 100 100 100 100
    fep0EventThreshold      = 100 100 100 100
    fep0SplitThreshold      = 80 80 80 80
    fep1SplitThreshold      = 80 80 80 80
    fep2SplitThreshold      = 80 80 80 80
    fep3SplitThreshold      = 80 80 80 80
    fep4SplitThreshold      = 80 80 80 80
    fep5SplitThreshold      = 80 80 80 80
    lowerEventAmplitude     = 800
    eventAmplitudeRange     = 3000
    gradeSelections         = 0xf*
    windowSlotIndex         = 2
    rawCompressionSlotIndex = 1
    biasAlgorithmId         = 1 1 1 1 1 1
    biasRejection           = 2 2 2 2 2 2
    deaLoadOverride         = 0
    fepLoadOverride         = 0
  }
  	      

  * the continuous clocking gradeSelections value consists of an optional `0x' followed by a hexadecimal digit (0-9, a-f).

3.2 lcmd

This program, described in detail in Section 10.18, reads a binary command file, e.g. one that was generated by buildCmds, and writes its contents to stdout in ASCII, e.g.

echo `read 4 fep 2 45678 600' | buildCmds | lcmd
	  

generates the following output:

readFep[0] = {
  commandLength              = 8
  commandIdentifier          = 4
  commandOpcode              = CMDOP_READ_FEP (4)
  fepId                      = 2
  readAddress                = 0x0000b26e
  wordCount                  = 600
}
	  

3.3 ltlm

This program, described in detail in Section 10.23, reads a stream of ACIS telemetry packets, e.g. one that was generated by getPackets or filterClient, and writes its contents to stdout in ASCII, e.g.

filterclient -m ps | ltlm
	  

might generate the following output:

scienceFramePseudo[0] = {
  synch                      = 0x736f4166
  telemetryLength            = 7
  formatTag                  = TTAG_PSEUDO_SCIENCE (62)
  sequenceNumber             = 0
  format                     = 2
  majorFrameId               = 0
  minorFrameId               = 0
  irigBdays                  = 935
  irigBsecs                  = 72260
  irigBmsecs                 = 0
  irigBusecs                 = 0
  bepSciTime                 = 0xa5997aff
}
bepStartupMessage[0] = {
  synch                      = 0x736f4166
  telemetryLength            = 7
  formatTag                  = TTAG_STARTUP (8)
  sequenceNumber             = 0
  bepTickCounter             = 0x00000237
  version                    = 2147483647
  lastFatalCode              = 0
  lastFatalValue             = 0
  watchdogFlag               = 0
  patchValidFlag             = 1
  configFlag                 = 1
  parametersFlag             = 1
}
	  

3.4 psci

This program, described in detail in Section 5, reads telemetry packets from stdin (e.g. the output of filterClient, outputs a continuous packet summary to stdout, and writes selected science data to disk files. Engineering pseudo-packets will be ignored. The summaries always include the following information from all packets to verify the ACIS execution sequence:

• packet type
• frame number

They also include detailed information that depends on the telemetry packet type for the purpose of verifying some detail of ACIS command execution. The information is written to stdoutin ASCII characters, one item per line.

In addition to its monitoring function, psci may also be commanded to extract specific data fields from telemetry packets and write them to disk files or pipes. psci generates several sets of log files, each one corresponds to a group of telemetry packets. The file content is identified by its name, examples of which are shown in Table 11.

3.5 analyzeData

This is a suite of programs to perform various data analysis functions, including those described in "Analysis Procedure".

3.6 runacis

This is a UNIX Bourne shell script that executes the BEP software simulator, acisBepUnix, described in Section 10.2, and a single copy of the FEP software simulator, acisFepUnix, Section 10.3, on a remote host. Its standard input stream, stdin, should consist of a binary ACIS command stream, e.g. as output by buildCmds. Its standard output stream, stdout, will consist of a stream of ACIS packets such as those generated by getPackets and filterClient. The user may specify as command line option the name of a shell script that generates a pixel stream to be read by acisFepUnix. runacis is described in detail in Section 10.27.

3.7 monitorDeaHousekeeping

This program reads ASCII-format DEA housekeeping summaries from stdin and displays their contents on a graphical interface. This program is being developed by ACIS EGSE personnel.

3.8 monitorEngineeringData

This program reads ASCII-format engineering summaries from stdin and displays their contents on a TBD graphical interface. This program is being developed by ACIS EGSE personnel.

3.9 monitorScience

This program reads ASCII-format packet summaries from stdin and displays their contents on a Tcl/Tk interface. It is described in detail in Section 10.24.

3.10 processEngineeringData

This program reads packets from stdin, inspects all engineering telemetry packets (ignoring the remainder), and writes to stdout a summary of these packets in a TBD format. This program is being developed by ACIS EGSE personnel.

4.0 Image Tools

Image operations fall into two categories: (a) simulating DEA output and feeding it into one or more Front End Processors (FEPs), and (b) intercepting real DEA output for off-line examination. The first task is accomplished by means of a "Frame Buffer", a dedicated hardware interface that down-loads pixels to the FEPs at a measured rate, and the latter by a "High-Speed Tap", essentially the same process in reverse.

4.1 getImages

The getImages command instructs an attached ARIEL signal processor to capture the output of a DEA controller via its high speed tap and to write it to a series of disk files. The format is described in Section 9.2.

4.2 putImages

putImages reads a stream of 16-bit pixels from stdin and writes them to an attached Frame Buffer for transmittal to one or more FEPs. The process is described in detail in Section 8.

4.3 genPixelImages

genPixelImages reads input commands from stdin and writes images to stdout in a format suitable for loading into the "Frame Buffer" described in Section 8. This format consists of 16 bit-words containing frame-buffer directives, FEP synchronization codes, and pixel and overclock values. Each image begins with four VSYNC codes and may contain from 1 to 1024 "rows", each beginning with four HSYNC codes. Each row may contain between 4 and 1024 "columns", divided into "nodes" (four in "ABCD" mode, two in either "AC" or "BD" mode), and followed by 0 to 15 pairs of overclocks per node. Note that the fourth, diagnostic, clocking mode generates no pixel values. It is therefore simulated by ÒABCDÓ mode and no separate genPixelImages option is required. This command is described in detail in Section 10.16.

4.4 loadFitsImage

This is an alternative to genPixelImages for creating binary pixel streams for the Frame Buffer (Section 8) from an existing 2-D FITS image such those created by putImages. This command is fully described in Section 10.21.

4.5 genObjectImage

This is an alternative to genPixelImages and loadFitsImage. Instead of defining the pixels row-by-row, its command language (read from stdin) defines the characteristics of the output image, of each of its output nodes, and of various objects ("events" and "blobs"), which are then located at various row and column addresses in the image. This command is fully described in Section 10.15.

4.6 generateExpectedData

This is a library of UNIX programs that duplicate the steps used by ACIS flight software in processing DEA pixel streams into raw pixel images, histograms, and photon event lists. Each step is implemented as a filter, permitting multiple to be applied in sequence to the same input data. The purpose of these programs is to repeat in a UNIX environment the operations executed by ACIS flight software in order to verify their correctness.

4.7 Image Tool Interfaces

The major external interfaces are between genPixelImages and putImages, and between getImages and various image display programs. Both interfaces may be described as a single stream of binary bytes, with no timing constraints.

4.7.1 stdin to putImages

The data stream sent from genPixelImages to putImagesconsists of 16-bit words, containing numeric data in their 12 least significant bits and codes in their 4 most significant bits. Some words are interpreted as local "directive functions" within the Frame Buffer (see Section 8. All other words are passed along to the FEPs, where their codes determine whether their 12-bit values are to be interpreted as CCD pixel data or overclocks, or whether the word is a no-op or FEP control code (HSYNC or VSYNC).

4.7.2 Output from getImages

The output from getImages consists of one or more files on magnetic disk. The files are written in FITS image format. Each set of VSYNC codes starts a new file. Within each image, each set of HSYNC codes begins a new row. The 4 most significant bits in each 16-bit data or overclock pixel are filled with zeroes. All other pixel types are ignored, i.e. they are not included in the output. The FITS headers are described in Section 9.2. The files are created with a user-specified base name, followed by a sequentially increasing frame number, followed by a file extension of ".fits".

Table of Contents

Previous Chapter

Next Chapter