These pages contain information about the USB controller based data acquisition software of the S800. Two crates are read by the software (one CAMAC and one VME), but more could be easily added to the software. The data format described here is irrelevant for the user. This is so because the USB data are “filtered” by the S800 Filter before being distributed to the user.

The CCUSB controller used to read data out of the CAMAC crate generates buffers of variable length. The first two words (16 bits each) are the buffer headers where information about the buffer is encoded. Events then follow until a single word 0xFFFF which is the buffer terminator. The format is as follows:

Header1 codes the number of events in bits 0-11. Bit14=1 indicates a scaler buffer, while bit15=1 indicates a watchdog buffer (not used in this implementation).

Header2 codes the number of words in the buffer in bits 0-11.

The format of events is as follows:

The length is the number of words following in the event. Note that IT IS NOT SELF-INCLUSIVE!

The word 0xC800 identifies the origin of the event as from the S800 CAMAC crate

The following 6 words encode the 48 bit event number

The tags and end tags identify the modules being read and encapsulate the data from each. The tags, end tags and their corresponding modules are listed below:

0x2367, 0xf367: LeCroy ULM2367 Trigger module

0x4300, 0xf300: LeCroy4300B FERA module for plastic scintillator energies

0x7164, 0xf164: Phillips7164 ADC module for ion chamber energies

0x7165, 0xf165: Phillips7164 ADC module for hodoscope energies 0 through 15

0x7166, 0xf166: Phillips7164 ADC module for hodoscope energies 16 through 31

0x7167, 0xf167: Phillips7164 ADC module for CRDC anodes (energies and TAC)

0x7186, 0xf168: Phillips7186 TDC module for time-of-flights

0x4448, 0xf448: LeCroy4448 coincidence register module for hodoscope hit pattern

The ULM trigger module provides a bit mask with information about the trigger sources, and a time-stamp value

The trigger bits words indicates which bits were set during the event. The encoding of the bits is the following:

The 64 bit time stamp (TS) follows from least significant word to most.

The data following the tag is the standard sparse FERA data as shown in the figure below:

At present (Oct 2015), the FERA channel assignments are:

The ADC data contains all channels for which the hit pattern bit is set. The channel number is encoded in bits 12-15, while the data is in bits 0-11. The ion chamber has 16 segments, channel 0 corresponding to the most upstream segment while channel 15 corresponding to the most downstream segment.

The ADC data contains all channels for which the hit pattern bit is set. The channel number is encoded in bits 12-15, while the data is in bits 0-11.

The ADC data contains all channels for which the hit pattern bit is set. The channel number is encoded in bits 12-15, while the data is in bits 0-11.

The ADC data contains all channels for which the hit pattern bit is set. The channel number is encoded in bits 12-15, while the data is in bits 0-11. The table below shows the channel assignments.

The TDC data contains all channels for which the hit pattern bit is set. The channel number is encoded in bits 12-15, while the data is in bits 0-11. The channel assignments can be found here

This tag is only used within scaler buffers, and contains the data from a 32 channels 24 bits LeCroy 4434 scaler module. The module is read in 24 bit mode, therefore the Q and X bits are encoded in bits 8 and 9 of the second 16-bit word, as specified in the CC-USB manual. The data format is therefore the following:

The VMUSB controller used to read data out of the VME crate generates buffers of variable length. The first two words (16 bits each) are the buffer headers where information about the buffer is encoded. Events then follow until two word 0xFFFF which are the buffer terminators. The format is as follows:

Header1 codes the number of events in bits 0-11. Bit14=1 indicates a scaler buffer, while bit15=1 indicates a watchdog buffer (not used in this implementation).

Header2 codes the number of words in the buffer in bits 0-11.

The format of events is as follows:

The length is the number of words following in the event. Note that IT IS NOT SELF-INCLUSIVE! This word also contains information about the stack that generated the data as well as a continuation bit indicating that the data spans more than the 2 kwords limit of the internal FIFO of the VMUSB. This bit is set for each contiguous fragment of the data until the last fragment for which it is not set. The mapping of the length word is the following:

The word 0xE800 identifies the origin of the event as from the S800 VME crate

The following 4 16-bit words encode the 64 bit event number

The tags and end tags identify the modules being read, and encapsulate their data. The tags, end tags and their corresponding modules are listed below:

0x5803: XLM72 module configured as a 64 bit time stamp

The S800 VME time-stamp module is implemented in a XLM72 (SpartanXL) FPGA. The coding of the time-stamp is given by:

The first two words following the tag indicate how many bytes of pad data follow. The pad data is organized in 64 bits words which are the contents of the static RAM of the XLM72V where the FPGA writes during the STAR front end board readout.

The STAR front end board readout sequence reads a total of 256 channels organized in groups of 4, each group containing the data of 4 boards for a given channel as a 40 bit wide data bus (each STAR FEE board digitizes on 10 bits). The mapping of the boards is such that the channel offset between groups of 10 bits is 64, for example if the first 10 bits correspond to channel 2, the following 10 bits correspond to channel 66, then 130, then 194. The channel number of the first 10 bits is encoded and runs from 0 to 63 (6 bits), as is the sample number which runs from 0 to 511 (9 bits). Since only the pads above threshold are written to the RAM, it happens quite frequently that only one group of 10 bits data is non-zero within the 64 bit word. This means that the data can be further compressed (which was done within the previous version of the readout using the SBS controllers).

The format of the 64 bit pad data is described below. The channel number is “c” and the sample number is “s”. The letter “x” indicates bits that are unused and can be ignored.

First 16 bit word (bits 0-15):

Second 16 bit word (bits 16-31):

Third 16 bit word (bits 32-47):

Fourth 16 bit word (bits 48-63):

The format for the pad data of crdc2 is exactly the same as for crdc1, with the exception of the tag of course.

The format for the strip data of the tracking PPACs is exactly the same as for crdc1, with the exception of the tag of course. These two PPACs located at the intermediate image are read by the same XLM72V module. Each has 64 strips in the horizontal and vertical planes, therefore the total number of channels is 256, the maximum that can be read by the STAR-based electronics.

This module implementation is only used for testing purposes on the S800 DAQ, but will be used as the hodoscope ADC on the Sweeper DAQ. The format of the data is determined by the module, and schematically shown below.

The formatting of the header, data words and ender are explained in the documentation of the module. Note that the number of 32 bits words contained in the header is not self-inclusive.

The Mesytec TDC module (MTDC) has multi-hit capabilities and a better resolution than the Phillips TDC. The format of the data is determined by the module, and schematically shown below.

The number of data words depend on the number of channels receiving signals, and the number of “hits” received on each channel. The figure below illustrates how the data are coded; in the example, the MTDC window has a -1017-ns delay (with respect to the trigger trig0) and 641-ns width.

Channel 0 has three consecutive hits: The second hit (time: t0,1) is processes as long as it is separated from the preceding hit (time: t0,0) by more than 160 ns (the conversion time); the third hit is not processed because it “arrived” to the MTDC after the matching window was closed. Channels 7 and 11 have a single hit each within the matching window. The resulting data structure is illustrated in the figure below: