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

TABLE 1. Command Type and Channel Definition
Command Type Command Channel Description
Name Value Name Value
Serial Digital 2 Software 2 Command used to control the ACIS software
Serial Digital 2 Hardware 3 Command used to control the ACIS hardware
High Level Pulse 0 Pulse Cmd Channel Number 0-98 PS and MC commands, whose action is determined by the Command Channel value
No-Op 3 TBD TBD Potential RCTU/CTUE operation commands

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.

TABLE 2. sendCmds Command Formats
Serial Digital Commands High Level Pulse Commands
Bit1 Contents Bit1 Contents
0 Unspecified 0 Unspecified
1-2 Command Type 1-2 Command Type
3-18 Command Data 3-14 Unspecified
19-23 Command Channel 15-23 Command Channel

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

TABLE 3. Header Format and Content
Packet Header
Fields
Field Length
(bits)
Science or
Housekeeping Packet
Science Frame
Pseudo-Packet
Engineering
Pseudo-Packet
Synch 32 0x736f4166 0x736f4166 0x736f4166
Length 10 Varying1 7 Varying1
Format Tag 6 Varying 62 61
Sequence Number 16 incremented by 1 for each packet in the telemetry stream 02 02

1 The packet length (number of 32 bit words) varies with the contents.
2 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.

TABLE 4. Science Frame Pseudo-Packet Format and Content
Field
Name
Source filterClient
Output
Format
Description
Location Start Length
format Virtual
Channel ID
bit 10 3 bits unsigned
int
Frame format identifier, either 1 (signifying 512 bps) or 2 (24 kbps), i.e. the AXAF tlm code + 1.
majorFrameId CCSDS
Header
bit 16 17 bits unsigned
int
Virtual Channel Data Unit Major Frame Counter (0 to 131071)
minorFrameId CCSDS
Header
bit 33 7 bits unsigned
short
Virtual Channel Data Unit Minor Frame Counter (0 to 127)
irigb Science
Header
byte 32 6 bytes unsigned
short [3]
Time (msec) from the IRIG-B interface
bepSciTime Science Data byte 56 4 bytes unsigned
int
Latched version of the BEP science pulse 1 MHz timestamp
Next-in-line
Data
TBD

TABLE 5. Engineering Pseudo-Packet Format and Content
Field
Name
Source filterClient
Output
Format
Description
Location Start Length
format Virtual
Channel ID
bit 10 3 bits unsigned
int
Frame format identifier, either 1 (signifying 512 bps) or 2 (24 kbps), i.e. the AXAF tlm code + 1.
majorFrameId CCSDS
Header
bit 16 17 bits unsigned
int
Major frame counter (0 to 131071)
followed by an array of one or more elements, each consisting of the following fields
data variable location within major frame var 8 bits unsigned
char
Engineering data
minorFrameId CCSDS
Header
bit 33 7 bits unsigned
char
Virtual Channel Data Uint Minor frame counter (0 to 127)
minorFrameByte


unsigned
short
Byte number in the minor frame (0 to 1024)

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.

TABLE 6. IRIG-B Field Format and Contents
Field Name Bit Length Byte Word
Julian Day 11 0,1 0
Seconds 17 1,2,3 0,1
Milliseconds 10 3,4 1,2
Microseconds (always zero) 10 4,5 2

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.

TABLE 7. filterClient packet classes
Class Packets
Selected
Description
SCI ACIS Science ACIS science packets corresponding to the format numbers 1 through 9 and 12 through 37
HKP DEA & S/W
Housekeeping
ACIS science packets corresponding to the two formats numbered 10 (TTAG_SW_HOUSE) and 11 (TTAG_DEA_HOUSE)
HDR Science Frame
Pseudo-Packet
Pseudo-Packets generated within getPackets containing science frame and BEP science timestamp information
ENG Engineering
Pseudo-Packet
Pseudo-Packets generated within getPackets containing ACIS and other spacecraft engineering channel readouts


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.

TABLE 8. Serial Commands to BEP Software
Command1 Arguments Description
add id cc badColumn file
id cc badColumn paramBlock
Add entries to the continuous clocking bad column block from binary file or in-line paramblock
id te badColumn file
id te badColumn paramBlock
Add entries to the timed exposure bad column block from binary file or in-line paramblock
id badPixel file
id badPixel paramBlock
Add entries to the timed exposure bad pixel map block from binary file or in-line paramblock
id patch patchId file Uplink a software patch from a binary file
change id systemConfig file
id systemConfig paramBlock
Change entries in the system configuration parameter block from binary file or in-line paramblock
continue id upLink file Continue uplink boot from a binary file
dump id badPixel Dump the bad pixel map block
id cc Dump all continuous clocking parameter blocks
id cc badColumn Dump the bad column map block used by continuous clocking science modes
id dea Dump the DEA housekeeping monitor parameter block
id huffman Dump all Huffman data compression tables
id patchList Dump the patch list
id systemConfig Dump the system configuration table
id te Dump all timed exposure parameter blocks
id te badColumn Dump the bad column map used by timed exposure science modes
id window1D Dump all 1-dimensional window blocks
id window2D Dump all 2-dimensional window blocks
exec id address [args] Execute the function located in the BEP memory at the specified address (a multiple of 4), with optional 32-bit arguments
id fep fepId address [args] Execute the function located at the specified address (a multiple of 4), in the memory of FEP number fepId, with optional 32-bit arguments
load id cc slotId file
id cc slotId paramBlock
Load a continuous clocking parameter block at the specified slotId from binary file or in-line paramblock
id dea slotId file
id dea slotId paramBlock
Load a DEA housekeeping parameter block at the specified slotId from binary file or in-line paramblock
id te slotId file
id te slotId paramBlock
Load a timed exposure parameter block at the specified slotId from binary file or in-line paramblock
id window1D slotId file
id window1D slotId paramBlock
Load a one-dimensional window parameter block at the specified slotId from binary file or in-line paramblock
id window2D slotId file
id window2D slotId paramBlock
Load a two-dimensional window parameter block at the specified slotId from binary file or in-line paramblock
read id address length Read length 32–bit words of BEP memory starting at the specified address
id fep fepId address length Read length 32–bit words of memory from FEP number fepId, starting at the specified address
id pram ccdId address length Read length 16–bit words of PRAM memory from DEA number ccdId, starting at the specified 16-bit word address
id sram ccdId address length Read length 16–bit words of SRAM memory from DEA number ccdId, starting at the specified 16-bit word address
remove id patch patchId Remove patchId from the software patch list
reset id badPixel Remove all entries from the bad pixel map
id cc badColumn Remove all entries from the continuous clocking bad column map
id te badColumn Remove all entries from the timed exposure bad column map
start id cc slotId Start a continuous clocking science run with parameters from slotId
id cc bias slotId Start a continuous clocking bias calculation with parameters from slotId
id dea slotId Start the DEA housekeeping monitor with parameters from slotId
id te slotId Start a timed exposure science run with parameters from slotId
id te bias slotId Start a timed exposure bias calculation with parameters from slotId
id upLink file Start an uplink boot from binary data in file
stop id dea Stop the currently executing DEA housekeeping monitor
id science Stop the currently executing science run
wait id seconds Suspend command output an integral number of seconds
write id address file Write the binary contents of file to BEP memory, starting at address (divisible by 4)
id fep fepId address file Write the binary contents of file to FEP number fepId, memory starting at address (divisible by 4)
id pram ccdId address file Write the binary contents of file to the PRAM memory of DEA number ccdId, starting at 16-bit word address
id sram ccdId address file Write the binary contents of file to the SRAM memory of DEA number ccdId, starting at 16-bit word address

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


TABLE 9. Serial Commands to BEP Hardware
Command Arguments Mnemonic 1 Description
halt bep 1RSETIRT Reset (i.e. halt) the BEP processor.
run bep 1RSETIRT Run the BEP processor. This is the default on BEP power up.
select bep bepId 1BSELICL Select which BEP to use (0 for BEP A, 1 for BEP B). The default on BEP power-up is 0 (BEP A).
eeprom mode 2 TBD Select the EEPROM mode: either PROGRAM for programmer data readout or TELEMETRY for software bi-level telemetry. The default on BEP power up is TELEMETRY.
set bootModifier mode 1BMODIBM Set the boot modifier mode: either ON to boot from uplink, or OFF to boot from ROM. The default on BEP power up is OFF.
radiationMonitor mode 1RMONIRM Set the radiation mode to HIGH or LOW. The default on DEA power up is LOW.
warmBoot mode 1SBYISB Set the warm boot flag ON or OFF.

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


TABLE 10. Pulse Commands to PSMC Hardware
Command Arguments 1 Mnemonic 2 Description 1
close door id MCDR*ON close door id
vent id VVCC*ON close vent valve id
relief id LVCC*ON close little vent valve id
closeabort door id MCDR*OF stop closing door drive id
vent id VVCC*OF stop closing vent valve id
disable daBake id HBO*DS disable commands to bakeout heater id
daHeater id HHTR*DS disable commands to housing heater id
dea id DEPS*DS disable commands to DEA power supply id
door id MCMD*DS disable commands to door mechanism drive id
dpa id DPPS*DS disable commands to DPA power supply id
pressure id PRES*DS disable pressure sensor id
relief id LVC*DS disable commands to little vent valve id
vent id VVC*DS disable commands to side vent valve id
enable daBake id HBO*EN enable commands to bakeout heater id
daHeater id HHTR*EN enable commands to housing heater id
dea id DEPS*EN enable commands to DEA power supply id
door id MCMD*EN enable commands to door mechanism drive id
dpa id DPPS*EN enable commands to DPA power supply id
pressure id PRES*EN enable pressure sensor id
relief id LVC*EN enable commands to little vent valve id
vent id VVC*EN enable commands to side vent valve id
open door id MODR*ON open door id
vent id VVCO*ON open vent valve id
relief id LVCO*ON open little vent valve id
openabort door id MODR*OF stop opening door drive id
vent id VVCO*OF stop opening vent valve id
poweroff daBake id HBO*OF power off bakeout heater id
daHeater id HHTR*OF power off housing heater id
dea id DEPS*OF power off DEA power supply id
dpa id DPPS*OF power off DPA power supply id
poweron daBake id HBO*ON power on bakeout heater id
daHeater id HHTR*ON power on housing heater id
dea id DEPS*ON power on DEA power supply id
dpa id DPPS*ON power on DPA power supply id
turnoff daBake HBOAOF
1HBOBOF
1HBOADS
1HBOBDS
power off and disable both bakeout heaters
daBake id HBO*OF
1HBO*DS
power off and disable bakeout heater id
daHeater HHTRAOF
1HHTRBOF
1HHTRADS
1HHTRBDS
power off and disable both housing heaters
daHeater id HHTR*OF
1HHTR*DS
power off and disable housing heater id
dea DEPSAOF
1DEPSBOF
1DEPSADS
1DEPSBDS
power off and disable both DEAs
dea id DEPS*OF
1DEPS*DS
power off and disable DEA id
dpa DPPSAOF
1DPPSBOF
1DPPSADS
1DPPSBDS
power off and disable both DPAs
dpa id DPPS*OF
1DPPS*DS
power off and disable DPA id
turnon daBake id HBO*EN
1HBO*ON
enable and power on bakeout header id
daHeater id HHTR*EN
1HHTR*ON
enable and power on housing heater id
dea id DEPS*EN
1DEPS*ON
enable and power on DEA id
dpa id DPPS*EN
1DPPS*ON
enable and power on DPA id

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

3.1.1 buildCmds Examples

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:

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
Peter G. Ford
Last modified: Thu Jan 9 12:42:13 EST