S800 Documentation

User Tools

Site Tools

Trace:
data_acquisition_daq

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision 		Previous revision
data_acquisition_daq [2013/12/11 19:37]
pereira 		data_acquisition_daq [2016/03/16 16:00] (current)
pereira
Line 2: Line 2:
   * [[USB Data Acquisition Setup Guide|USB Data Acquisition Setup Guide]]   * [[USB Data Acquisition Setup Guide|USB Data Acquisition Setup Guide]]
   * [[S800 USB DAQ data format|S800 USB DAQ data format]]   * [[S800 USB DAQ data format|S800 USB DAQ data format]]
-  * [[S800 data format|S800 data format]] +  * [[Event Filter|S800 data format from Event Filter (S800 Filter)]]
-  * [[DAQ run control protocol|DAQ run control protocol]] +
-  * [[Event Builder|Event Builder]] +
-  * [[S800 + Gretina|S800 + Gretina]]+
   * [[Scaler Channel Description|Scaler Channel Description]]   * [[Scaler Channel Description|Scaler Channel Description]]
- +  * [[S800 DAQ tools]] 
- +  * [[How to run combined S800 + GRETINA]]   
- +  * [[S800 Versioning system|Versioning system]]
-===== USB Data Acquisition Setup Guide ===== +
-This page contains information on the USB-based data acquisition running on the NSCL-supported devices. It is intended to provide a better understanding of the software and a way for users to setup or modify the configurations to their needs. +
- +
-The USB-based data acquisition is built around the VM-USB (VME) and CC-USB (CAMAC) crate controllers available from Wiener Electronics. These controllers contain at their core an FPGA on which the controller firmware is loaded. The controllers have two modes of operation: +
- +
-  - Interactive mode: commands sent to the USB port are immediately executed and their result returned +
-  - Data acquisition mode: the controller executes a list of commands preloaded in a stack upon a trigger condition (event, interrupt or periodic) +
- +
-The first mode is typically used when setting up the modules contained in the crate, such as gains, thresholds and so on, while the second mode is used for acquiring event-driven data. The two modes are mutually exclusive, and issuing an interactive command while in data acquisition mode will typically result in an error or lockup of the controller. +
- +
-The USB DAQ is a Tcl-based software using a simple API library to handle the low-level handling of the data. It is capable of handling multiple crate controllers (CC-USB or VM-USB) connected to the same computer. Each controller is polled by an independent thread which then sends the data through a predefined TCP/IP port.  +
- +
-The machine-level calls to the USB interface are handled by a library called "libusb" which is widely available on many platforms (Linux, OS X, Windows). The installation of this library is mandatory in order to use this data acquisition system. Wiener Electronics provides a C library called "libxxusb" built on top of libusb with subroutines tailored to the VM-USB and CC-USB. The USB DAQ in turn uses this library in a Tcl API written to interface the C subroutines of libxxusb to the Tcl world. The library implementing this API is called "libTclXXUSB". It also contains custom subroutines used in sending data through TCP/IP ports. +
- +
-The data streams coming from the various crates are synchronized and combined into a single stream by the event builder program (written in C). This program connects to the TCP/IP ports of the USB DAQ as a client. It also checks the sanity of the buffers before assembling them into NSCL standard buffers. +
- +
-The software is distributed into the following folder structure: +
-  * TclXXUSB: contains the USB DAQ main program (RunControl.tcl) as well as class definitions for different types of modules +
-  * libTclXXUSB: contains the Wiener Electronics library libxxusb as well as the Tcl API implemented in libTclXXUSB +
-  * eventbuild: contains the event builder program and its debug files +
-  * Scripts: contains the Tcl scripts for the various crates and sequences +
-  * Configs: contains the configuration files of the various modules used in the setup +
- +
- +
- +
- +
- +
- +
- +
- +
- +
- +
- +
-===== S800 USB DAQ data format ===== +
- +
-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. +
- +
-==== CAMAC Crate data format ==== +
-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: +
- +
-{| class="wikitable" +
-| Header1 +
-| Header2 +
-| Events... +
-| 0xFFFF +
-|} +
- +
-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: +
- +
-{| class="wikitable" +
-| Length +
-| 0xC800 +
-| Event counter bits 0-15 +
-| Event counter bits 16-23 +
-| Event counter bits 24-39 +
-| Event counter bits 40-47 +
-| Tag +
-| Data... +
-| End Tag +
-| Tag +
-| Data... +
-| End Tag +
-| ... +
-|} +
- +
-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 +
- +
-=== Tag 0x2367: Trigger module === +
- +
-{| class="wikitable" +
-| 0x2367 +
-| Trigger bits +
-| TS 0-15 +
-| TS 16-31 +
-| TS 32-47 +
-| TS 48-63 +
-| 0xf367 +
-|} +
- +
-The trigger bits words indicates which bits were set during the event. The encoding of the bits is the following: +
- +
-{| class="wikitable" +
-| Bit +
-| Source +
-|- +
-| 0 +
-| S800 +
-|- +
-| 1 +
-| Coincidence +
-|- +
-| 2 +
-| External 1 +
-|- +
-| 3 +
-| External 2 +
-|- +
-| 4 +
-| Secondary +
-|} +
- +
-<br style="clear: both" /> +
- +
-The 64 bit time stamp (TS) follows from least significant word to most. +
- +
-=== Tag 0x4300: FERA module for plastic scintillator energies === +
- +
-{| class="wikitable" +
-| 0x4300 +
-| FERA data... +
-| 0xf300 +
-|} +
- +
-The data following the tag is the standard sparse FERA data as shown in the figure below: +
- +
-[[File:FERAData.png|left|Format of LeCroy 4300B FERA data]] +
- +
- +
-<br style="clear: both" /> +
-=== Tag 0x7164: Phillips 7164 ADC module for ion chamber energies === +
- +
-{| class="wikitable" +
-| 0x7164 +
-| hit pattern +
-| ADC data... +
-| 0xf164 +
-|} +
- +
-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. +
- +
-<br style="clear: both" /> +
-=== Tag 0x7165: Phillips 7164 ADC module for hodoscope energies 0 through 15 === +
- +
-{| class="wikitable" +
-| 0x7165 +
-| hit pattern +
-| ADC data... +
-| 0xf165 +
-|} +
- +
-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. +
- +
- +
-<br style="clear: both" /> +
-=== Tag 0x7166: Phillips 7164 ADC module for hodoscope energies 16 through 31 === +
- +
-{| class="wikitable" +
-| 0x7166 +
-| hit pattern +
-| ADC data... +
-| 0xf166 +
-|} +
- +
-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. +
- +
- +
-<br style="clear: both" /> +
-=== Tag 0x7167: Phillips 7164 ADC module for CRDC anodes (energies and TAC) === +
- +
-{| class="wikitable" +
-| 0x7167 +
-| hit pattern +
-| ADC data... +
-| 0xf167 +
-|} +
- +
-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. +
- +
-{| class="wikitable" +
-| Channel  +
-| Assignment +
-|- +
-| 0 +
-| Available +
-|- +
-| 1 +
-| CRDC1 Anode +
-|- +
-| 2 +
-| CRDC2 Anode +
-|- +
-| 3 +
-| CRDC1 TAC +
-|- +
-| 4 +
-| CRDC2 TAC +
-|- +
-| 5-6 +
-| Available +
-|- +
-| 7 +
-| XF TAC +
-|- +
-| 8 +
-| Object TAC +
-|- +
-| 9-14 +
-| Available +
-|- +
-| 15 +
-| Hodoscope TAC +
-|} +
- +
-<br style="clear: both" /> +
- +
-=== Tag 0x7186: Phillips 7186 TDC module for time-of-flights === +
- +
-{| class="wikitable" +
-| 0x7186 +
-| hit pattern +
-| ADC data... +
-| 0xf186 +
-|} +
- +
-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 table below shows the channel assignments. +
- +
-{| class="wikitable" +
-| Channel  +
-| Assignment +
-|- +
-| 0 +
-| E1_up +
-|- +
-| 1 +
-| E1_down +
-|- +
-| 2-7 +
-| Available +
-|- +
-| 8 +
-| S800 source +
-|- +
-| 9 +
-| External 1 source +
-|- +
-| 10 +
-| External 2 source +
-|- +
-| 11 +
-| Secondary source +
-|- +
-| 12 +
-| RF TOF +
-|- +
-| 13 +
-| Object TOF +
-|- +
-| 14 +
-| XF TOF +
-|- +
-| 15 +
-| Available +
-|} +
- +
-<br style="clear: both" /> +
- +
-=== Tag 0x4448: LeCroy4448 coincidence register module for hodoscope hit pattern === +
- +
-{| class="wikitable" +
-| 0x4448 +
-| hit pattern 0-15 +
-| hit pattern 16-31 +
-| 0xf448 +
-|} +
- +
-=== Tag 0x4434: LeCroy4434 scaler module === +
-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 CCUSB manual. The data format is therefore the following: +
- +
-{| class="wikitable" +
-| 0x4434 +
-| 16 lower bits of channel 1 +
-| 0x03hh where hh are the 8 higher bits of channel 1 +
-| and so on until channel 32...  +
-|} +
- +
-=VME Crate data format= +
-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: +
- +
-{| class="wikitable" +
-| Header1 +
-| Header2 +
-| Events... +
-| 0xFFFF +
-| 0xFFFF +
-|} +
- +
-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: +
- +
-{| class="wikitable" +
-| Length +
-| 0xE800 +
-| Event counter bits 0-15 +
-| Event counter bits 16-31 +
-| Event counter bits 32-47 +
-| Event counter bits 48-63 +
-| Tag +
-| Data... +
-| End Tag +
-| Tag +
-| Data... +
-| End Tag +
-| ... +
-|} +
- +
-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: +
- +
-{| class="wikitable" +
-| 15-13 +
-| 12 +
-| 11-0 +
-|- +
-| Stack ID +
-| Continuation bit +
-| Length +
-|} +
- +
-The word 0xE800 identifies the origin of the event as from the S800 VME crate +
- +
-The following 6 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 +
- +
-=== Tag 0x5803: XLM72 time stamp module === +
- +
-{| class="wikitable" +
-| 0x5803 +
-| TS bits 0-15 +
-| TS bits 16-31 +
-| TS bits 32-47 +
-| TS bits 48-63 +
-| 0xF803 +
-|} +
- +
-=== Tag 0xCFDC: XLM72V crdc1 pad readout module === +
- +
-{| class="wikitable" +
-| 0xCFDC +
-| Bytes (bits 0-15) +
-| Bytes (bits 16-31) +
-| Pad data (bits 0-15) +
-| Pad data (bits (16-31) +
-| Pad data (bits 32-47) +
-| Pad data (bits (48-63) +
-| ... +
-| 0xFFDC +
-|} +
- +
-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):  +
-{| class="wikitable" +
-| Data of channel c+64 (bits 0-5) +
-| Data of channel c (bits 0-9) +
-|} +
- +
-Second 16 bit word (bits 16-31):  +
-{| class="wikitable" +
-| x +
-| x +
-| Data of channel c+128 (bits 0-9) +
-| Data of channel c+64 (bits 6-9) +
-|} +
- +
-Third 16 bit word (bits 32-47):  +
-{| class="wikitable" +
-| x +
-| x +
-| x +
-| x +
-| x +
-| x +
-| Data of channel c+192 (bits 0-9) +
-|} +
- +
-Fourth 16 bit word (bits 48-63): +
- +
-{| class="wikitable" +
-| x +
-| Sample s (bits 0-8) +
-| Channel c (bits 0-5) +
-|} +
- +
-=== Tag 0xCFDD: XLM72V crdc2 pad readout module === +
-The format for the pad data of crdc2 is exactly the same as for crdc1, with the exception of the tag of course. +
- +
-=== Tag 0x5870: XLM72V tracking ppac readout module === +
-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. +
- +
-=== Tag 0xADC1: Mesytec MADC-32 module === +
-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. +
- +
-{| class="wikitable" +
-| 0xADC1 +
-| Header (0-15) +
-| Header (16-31) +
-| Data word (0-15) +
-| Data word (16-31) +
-| ... +
-| Ender (0-15) +
-| Ender (16-31) +
-| 0xFDC1 +
-|} +
- +
-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. +
- +
-[[File:MADC32Data.png|left|Format of Mesytec MADC-32 data]] +
- +
-[[File:MADC32Data2.png|left|Format of Mesytec MADC-32 data]]+
  
data_acquisition_daq.1386808635.txt.gz · Last modified: 2013/12/11 19:37 by pereira

Page Tools

Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Noncommercial-Share Alike 4.0 International
CC Attribution-Noncommercial-Share Alike 4.0 International Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki