The GSI Fragment Separator Website
Your portal to information about the FRS!
 People   Research   Meetings   Technical info 
You are in GSI » FRS » Technical » FRS data acquisition » FRS stand-alone system » FRS data structure in single-event mode

FRS data structure in single-event mode

The migration from CAMAC to VME has led to a completely new data structure for FRS events. Whereas some features of the older system have disappeared (such as the dT 1 MHz scaler), new ones have become standard (e.g. time stamp).

The VME ADCs, TDCs and QDCs can all be operated in zero-suppression and/or overflow suppression mode, and individual input channels can be enabled or disabled by software. This necessitates the "tagging" of each converted value with channel number and slot (also called GEO), as well as the implementation of header and footer blocks clearly demarcating the data originating from individual modules - something that was not needed in the old fixed-length readout used with the CAMAC-based system.

This document aims at introducing the new data format and to suggest way to implement the unpacking of the data.

A typical event

As not all the VME modules deliver their data in "compatible" format, some restraints have been placed on the readout order - and thus on the event structure. In addition, some small modifications to the data structures inherent to the VME modules have been made in the readout function (f_user.c and associated files) - see the relevant documentation!

A typical event could look like this (visualized by the MBS program):

....
....

The first 4 longwords contain time stamp information. This is followed by 10 longwords from the scaler: 1 header longword + 8 longwords (one per channel) + 1 footer longword. Then comes 4 longwords from the pattern unit: 1 header longword + 2 data longwords + 1 footer longword]. Then data from each accessed ADC, TDC and QDC module follows, formatted using a standard recipe (per module minimum 1 longword, maximum 34 longwords).

Time stamp

See Notes below for additional information!

Longword 1: (time stamp unit identifier)
bits 0-15: FRS branch = 512 (0x200)
bits 16-31: all zero (0x0)

Longword 2: (time stamp word 1)
bits 0-15: data
bits 16-31: word 1 identifier = 247 (0x00f7)

Longword 3: (time stamp word 2)
bits 0-15: data
bits 16-31: word 1 identifier = 503 (0x01f7)

Longword 4: (time stamp word 3)
bits 0-15: data
bits 16-31: word 1 identifier = 759 (0x02f7)

Scaler

Because the scaler is a 32-bit one, there is no room for channel information to be recorded together with the data. The data is therefore delivered sequentially, starting from channel 0 up to the maximum number of read cheannels. (This is specified in the f_user.c file.)

Longword 1: (header = scaler identifier)
bits 0-5: number of read channels = chn
bits 6-23: all zero
bits 24-26: header flag = 2 (0x2, 010b)
bits 27-31: scaler GEO = 6 (0x6, 00110b)

Longwords 2 -- chn+1: (scaler data, sequential)
bits 0-31: channel contents

Longword chn+2: (footer = end-of-block)
bits 0-26: all zero
bits 24-26: footer flag = 4 (0x4, 100b)
bits 27-31: scaler GEO = 6 (0x6, 00110b)

Pattern unit

As of 07-Oct-2003, the pattern unit readout is implemented!
The data returned is fixed-length (4 longwords) and a hardwired GEO address 5.

Longword 1: (header = pattern unit identifier)
bits 0-5: number of data longwords = 2
bits 6-23: all zero
bits 24-26: header flag = 2 (0x2, 010b)
bits 27-31: pattern unit GEO = 5 (0x5, 00101b)

Longword 2: (data 1)
bits 0-15: pattern unit bit register
bits 16-23: data word 0 (0x0, 00000000b)
bits 24-26: data flag = 0 (0x0, 000b)
bits 27-31: pattern unit GEO = 5 (0x5, 00101b)

Longword 2: (data 2)
bits 0-15: pattern unit multiplicity register
bits 16-23: data word 1 (0x1, 00000001b)
bits 24-26: data flag = 0 (0x0, 000b)
bits 27-31: pattern unit GEO = 5 (0x5, 00101b)

Longword n: (footer = end-of-block)
bits 0-23: all zero
bits 24-26: footer flag = 4 (0x4, 110b)
bits 27-31: pattern unit GEO = 5 (0x5, 00101b)

ADCs, QDCs and TDCs

Two cases can be distinguished: either valid data is present or not. The latter case can e.g. occur if there were no valid input signals, if all channels were disabled, etc., and is distinguished by the presence of a single longword. If at least one valid datum is present, the data structure will have the form header + data + footer.

No valid data

Longword 1: (header)
bits 0-5: number of data longwords = 0
bits 6-23: all zero
bits 24-26: no-valid-data flag = 6 (0x6, 110b)
bits 27-31: unit GEO

Valid data present

Longword 1: (header = scaler identifier)
bits 0-5: number of read channels = chn
bits 6-23: all zero
bits 24-26: header flag = 2 (0x2, 010b)
bits 27-31: unit GEO

Longwords 2 -- chn+1: (data)
bits 0-11: channel contents
bit 12: underflow bit
bit 13: overflow bit
bits 14-15: all zero
bits 16-20: channel number
bits 24-26: data flag = 0 (0x0, 000b)
bits 27-31: unit GEO

Longword chn+2: (footer = end-of-block)
bits 0-15: unit event counter
bits 16-26: all zero
bits 24-26: footer flag = 4 (0x4, 110b)
bits 27-31: unit GEO

------------------------------------
Note: 1 byte = 8 bits, 1 word = 2 bytes = 16 bits, 1 longword = 2 words = 4 bytes = 32 bits.
Bits are counted from 0 and upward, and written out with the least significant bits (LSBs) to the right. 10010110b (binary notation) = 0x96 (hexadecimal notation) = 150 (decimal notation).

Note 2: MBS writes out data in "swapped" word order, which corresponds to word1, word2 (or byte2, byte1, byte4, byte3) - this can be a bit confusing at first... When you type an event on screen, all data is presented in hexadecimal notation. For instance the 8 words of the time stamp information could look like "200 0 17ff f7 38e1 1f7 563 2f7" where longword 1 = 0x00000200, longword 2 = 0x00f717ff, longword 3 = 0x01f738e1 and longword 4 = 0x02f70563.

 
Comments? Questions? Error reports? Please contact the webmaster!
The FRS web pages have been accessed 27002 times since October 27, 2003!
Script file last updated on July 21, 2006.