Differences

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

--- sweeper_usb_daq_data_format [2017/05/07 16:43]
pereira [CAMAC Crate data format]
+++ sweeper_usb_daq_data_format [2017/06/11 17:26] (current)
pereira [The Sweeper USB DAQ data format]
@@ Line 1: / Line 1: @@
 ====== The Sweeper USB DAQ data format ======
-Two crates are read by the Sweeper DAQ software (one CAMAC and one VME), but more could be easily added to the software. This section describes the data format coming from each controller. (Please, note that this data format  is irrelevant for the user; this is so because the USB data are "pre-unpacked" by the [[Pre-unpacker|Sweeper Pre-unpacker]] software before being distributed to the user.)
+Two crates are read by the Sweeper DAQ software, one CAMAC and one VME. Data from each of these controllers are pushed into [[http://docs.nscl.msu.edu/daq/newsite/nscldaq-11.2/c43.html|ring buffers ]] (**rawccusb** for CCUSB and **rawvmusb** for VMUSB). The Sweeper Event Builder (EVB) reads  data from these ring-buffers, correlates them on the basis of their time stamps, and outputs the resulting data stream on the ring buffer **sweeper**. According to the NSCLDAQ 11.x [[http://docs.nscl.msu.edu/daq/newsite/nscldaq-11.2/x4509.html|format]], data in the ring buffer **sweeper** will be organized in ring items, each consisting of two fragments, one for each controller.
+The structure of the data from the Sweeper EVB is schematically illustrated in the figure below:
+{{:wiki:diagram_ringitem_fromevb.png?800|Schematic representation of data format from Sweeper EVB}}
+Events from the Sweeper EVB will be encapsulated in ring items, consisting of header, a body header, and a body. The body part contains two fragments, one from each controller. Each fragment has a header, followed, again, by a ring item (with its corresponding header, body header, and body).
+The structure from the body of each fragment is described below in some detail. Please, note that this data format  is irrelevant for the user; this is so because the USB data are "pre-unpacked" by the [[Pre-unpacker|Sweeper Pre-unpacker]] software before being distributed to the user.
@@ Line 26: / Line 33: @@
 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:
-x2367, 0xf367: LeCroy ULM2367 Trigger module
+  * 0x2367, 0xf367: LeCroy ULM2367 Trigger module
+  * 0x4300, 0xf300: LeCroy4300B FERA module for plastic scintillator energies
-x4300, 0xf300: LeCroy4300B FERA module for plastic scintillator energies
+  * 0x7164, 0xf164: Phillips7164 ADC module for ion chamber energies
-x7164, 0xf164: Phillips7164 ADC module for ion chamber energies
+  * 0x7167, 0xf167: Phillips7164 ADC module for CRDC anodes (energies and TAC)
-x7167, 0xf167: Phillips7164 ADC module for CRDC anodes (energies and TAC)
-x7186, 0xf168: Phillips7186 TDC module for time-of-flights (NOT INCLUDED IN NEW DAQ)
+  * 0x7186, 0xf168: Phillips7186 TDC module for time-of-flights (DISCONTINUED)
@@ Line 101: / Line 108: @@
 | 4 | CRDC2 TAC |
 | 5-15 | Available |
+===== 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:
+^ 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:
+^ Length ^ 0xE801 ^ 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:
+^ 15-13 ^ 12 ^ 11-0 |
+| Stack ID | Continuation bit | Length |
+The word 0xE801 identifies the origin of the event as from the Sweeper 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:
+  * 0x5901, 0xf901: trigger pattern from Level-3 trigger module (XLM72)
+  * 0x5903, 0xf903: time stamp pattern from Level-3 trigger module (XLM72)
+  * 0xcfdc, 0xffdc: XLM72 module configure to read CRDC1 pad signals
+  * 0xcfdd, 0xffdd: XLM72 module configure to read CRDC2 pad signals
+  * 0x59b0, 0xf9b0: MADC-32 module for Hodoscope
+  * 0x59b0, 0xf9b0: MADC-32 module for Segmented Target
+  * 0x0ddc, 0xfddc: MTDC-32 module for time-of-flights

Sweeper Magnet

User Tools

Site Tools

Differences

Page Tools