Difference: HadesRawDataFormat (1 vs. 8)

Revision 8
02 Oct 2008 - Main.MichaelBoehmer
Line: 1 to 1
 
META TOPICPARENT name="HadesDaqDocumentation"

HADES raw data format

Revision 7
02 Oct 2008 - Main.MichaelBoehmer
Line: 1 to 1
 
META TOPICPARENT name="HadesDaqDocumentation"

HADES raw data format

Line: 127 to 127
  Every event contains zero to unspecified many subevents. As an empty event is allowed, data outside of any subevent are not allowed. A subevents consists out of a fixed size subevent header and a varying number of data words.
Changed:
<
<
  • The subevent header \br
>
>
  • The subevent header
 
subEvtHeader
subEvtSize subEvtDecoding subEvtId subEvtTrigNr
    • subEvtSize - size of the subevent: This includes the the subevent header, it is measured in bytes.
Line: 152 to 152
 
800-899 TRB_HOD pion-hodoscope
900-999 TRB_FW forward wall
1000-1099 TRB_START start detector
Changed:
<
<
1100-1199 TRB_TOF TOF-detector
>
>
1100-1199 TRB_TOF TOF detector
1200-1299 TRB RICH RICH detector
  Additionally, all subEvtIds may have the MSB set. This indicates a sub event of the corresponding id that contains broken data (e.g. parity check failed, sub event was too long etc.).
    • subEvtTrigNr - subevent Trigger Number: This is the event tag that is produced by the trigger system and is used for checking the correct assembly of several sub entities. In general, this number is not counting sequentially. The lowest significant byte represents the trigger tag generated by the CTU and has to be same for all detector subsystems in one event. The rest is filled by the EB.
  • The data words: The format of the data words (word length, compression algorithm, sub-sub-event format) is defined by the subEvtDecoding and apart from this it is completely free. The meaning of the data words (detector, geographical position, error information) is defined by the subEvtId and apart from this it is completely unknown to the data acquisition system.
Revision 6
18 Jul 2008 - Main.MichaelTraxler
Line: 1 to 1
 
META TOPICPARENT name="HadesDaqDocumentation"

HADES raw data format

Line: 20 to 20
 
  • v1.6 by M. Münch, change in structure, added the appendix for assigned numbers following a discussion about the versioning of the event id
  • v1.7 by M. Traxler, added new subevent ids for TRB-kind-subevents
  • v1.8 by J.Wuestenfeld, corrected Subevent Id tables to match
Changed:
<
<
>
>
  • v1.9 by M. Jurkovich, cleanup and adding some information
 

project status: current

Logical structure

Line: 84 to 84
 
2,3,4,5,6,7,8,9 calibration
13 beginrun
14 endrun
Changed:
<
<
<\br>
>
>

 
ID after SEP03 description
0 simulation
1,2,3,4,5 real
Revision 5
17 Jul 2008 - Main.MartinJurkovic
Line: 1 to 1
 
META TOPICPARENT name="HadesDaqDocumentation"

HADES raw data format

Line: 44 to 44
 
  • If byte swapping is necessary, it must be done in four byte units (32bit words), unless it is defined explicitly otherwise. * All divisions start with a word describing the size of the whole division in bytes. This includes the size word itself.
Changed:
<
<

Description of the sub divisions

>
>

Description of the Event Structure

 
Changed:
<
<

Event

>
>
An event consists of an event header and of varying number of subevents, each with a subevent header. The size of the event header is fixed to 0x20 bytes
 
Changed:
<
<
Events consist out of a fixed size event header and a varying number of variable size subevents.

Event header:

evtHeader
>
>

Event header

evtHeader
 
evtSize evtDecoding evtId evtSeqNr evtDate evtTime runNr expId
Changed:
<
<
  • evtSize - size of the event: This includes the event header, it is measured in bytes.
  • evtDecoding - event decoding type: Tells the analysis the binary format of the event data, so that it can be handed to a corresponding routine for unpacking into a software usable data structure. For easier decoding of this word, the meaning of some bits is already predefined:
    evtDecoding
    msb --- --- lsb
    0 alignment decoding type
  1. The first (most significant) byte is always zero.
  2. The second byte contains the alignment of the subevents in the event. 0 = byte, 1 = 16 bit word, 2 = 32 bit word...
  3. The remaining two bytes form the actual decoding type, e.g. fixed length, zero suppressed etc. The last byte must not be zero, so the whole evtDecoding can be used to check for correct or swapped byte order.
>
>
  • evtSize - total size of the event including the event header, it is measured in bytes.
  • evtDecoding - event decoding type: Tells the analysis the binary format of the event data, so that it can be handed to a corresponding routine for unpacking into a software usable data structure. For easier decoding of this word, the meaning of some bits is already predefined:
    evtDecoding
    msB --- --- lsB
    0 alignment decoding type nonzero
    • The first (most significant) byte is always zero.
    • The second byte contains the alignment of the subevents in the event. 0 = byte, 1 = 16 bit word, 2 = 32 bit word...
    • The remaining two bytes form the actual decoding type, e.g. fixed length, zero suppressed etc.
    • The last byte must not be zero, so the whole evtDecoding can be used to check for correct or swapped byte order.
  It is stated again, that the whole evtDecoding is one 32bit word. The above bit assignments are merely a rule how to select this 32bit numbers.
Changed:
<
<

  • evtId - event identifier: Tells the analysis the semantics of the event data, e.g. if this is a run start event, data event, simulated event, slow control data, end file event, etc..
  • evtSeqNr - event number: This is the sequence number of the event in the file. The pair evtFileNr/evtSeqNr is unique throughout all events ever acquired by the system. *evtDate - date of event assembly:
    evtDate
    msb --- --- lsb
>
>
  • evtId - event identifier: Tells the analysis the semantics of the event data, e.g. if this is a run start event, data event, simulated event, slow control data, end file event, etc..
    evtId
    31 30 - 16 15 - 12 11 - 8 5 - 7 4 3- 0
    error bit reserved version reserved MU decision DS flag ID
    • error bit - set if one of the subsystems has set the error bit
    • version - 0 meaning of event ID before SEP03; 1 event ID after SEP03
    • MU decision - 0 = negative LVL2 decision; >0 positive LVL2 decision
      MU trigger algo result
      1 negative decision
      2 positive decision
      3 positive decision due to too many leptons or dileptons
      4 reserved
      5 reserved
    • DS flag - LVL1 downscaling flag; 1 = this event is written to the tape independent on the LVL2 trigger decision
    • ID - defines the trigger code
      ID before SEP03 description
      0 simulation
      1 real
      2,3,4,5,6,7,8,9 calibration
      13 beginrun
      14 endrun
      <\br>
      ID after SEP03 description
      0 simulation
      1,2,3,4,5 real
      7,9 calibration
      1 real1
      2 real2
      3 real3
      4 real4
      5 real5
      6 special1
      7 offspill
      8 special3
      9 MDCcalibration
      10 special5
      13 beginrun
      14 endrun
  • evtSeqNr - event number: This is the sequence number of the event in the file. The pair evtFileNr/evtSeqNr
is unique throughout all events ever acquired by the system.
  • evtDate - date of event assembly (filled by the event builder, rough precision):
    evtDate ISO-C date format
    msB --- --- lsB
 
0 year month day
  1. The first (most significant) byte is zero
  2. The second byte contains the years since 1900
  3. The third the months since January [0-11]
  4. The last the day of the month [1-31]
Changed:
<
<

(this is the date format of ISO-C)
  • evtTime - time of assembly:
    evtTime
    msb --- --- lsb
>
>
  • evtTime - time of assembly (filled by the event builder, rough precision):
    evtTime ISO-C time format
    msB --- --- lsB
 
0 hour minute second
  1. The first (most significant) byte is zero
  2. The second byte contains the hours since midnight [0-23]
  3. The third the minutes after the hour [0-59]
  4. The last the seconds after the minute [0-60]
Changed:
<
<

(this is the time format of ISO-C)

The date and time field are filled in by the event builder and have thus only rough precision.
  • evtFileNr - file number: A unique number assigned to the file. The evtFileNr can be used as key to the run database.
  • evtPad - padding: Makes the event header a multiple of 64 bits long.

  • The subevents: Every event contains zero to unspecified many subevents. An empty event is allowed, data outside any subevent is not allowed.
>
>
  • runNr - file number: A unique number assigned to the file. The runNr is used as key for the RTDB.
  • evtPad - padding: Makes the event header a multiple of 64 bits long.
 

Subevent

Changed:
<
<
Subevents consist out of a fixed size subevent header and a varying number of data words.
>
>
Every event contains zero to unspecified many subevents. As an empty event is allowed, data outside of any subevent are not allowed. A subevents consists out of a fixed size subevent header and a varying number of data words.
 
Changed:
<
<
>
>
  • The subevent header \br
    subEvtHeader
 
subEvtSize subEvtDecoding subEvtId subEvtTrigNr
Changed:
<
<
  1. subEvtSize - size of the subevent: This includes the the subevent header, it is measured in bytes.
  2. subEvtDecoding - subevent decoding type: Tells the analysis the binary format of the subevent data, so that it can be handed to a corresponding routine for unpacking into a software usable data structure. For easier decoding of this word, the meaning of some bits is already predefined:
    subEvtDecoding
    msb --- --- lsb
    0 data type decoding type
    1. The first (most significant) byte is always zero
    2. The second byte contains the word length of the subevent data. 0 = byte, 1 = 16 bit word, 2 = 32 bit word...
    3. The remaining two bytes form the actual decoding type, e.g. fixed length, zero suppressed etc. The last byte must not be zero, so the whole subEvtDecoding can be used to check for correct or swapped byte order.
>
>
    • subEvtSize - size of the subevent: This includes the the subevent header, it is measured in bytes.
    • subEvtDecoding - subevent decoding type: Tells the analysis the binary format of the subevent data, so that it can be handed to a corresponding routine for unpacking into a software usable data structure. For easier decoding of this word, the meaning of some bits is already predefined:
      subEvtDecoding
      msB --- --- lsB
      0 data type decoding type nonzero
      • The first (most significant) byte is always zero
      • The second byte contains the word length of the subevent data. 0 = byte, 1 = 16 bit word, 2 = 32 bit word...
      • The remaining two bytes form the actual decoding type, e.g. fixed length, zero suppressed etc.
      • The last byte must not be zero, so the whole subEvtDecoding can be used to check for correct or swapped byte order.
  It is stated again, that the whole subEvtDecoding is one 32bit word. The above bit assignments are merely a rule how to select this 32bit numbers.
Changed:
<
<
  • subEvtId - subevent identifier: Tells the analysis the semantics of the subevent data, e.g. every subevent builder may get its own subEvtId. So the data structure can be analyzed by the corresponding routine after unpacking.
  • subEvtTrigNr - subevent Trigger Number: This is the event tag that is produced by the trigger system and is used for checking the correct assembly of several sub entities. In general, this number is not counting sequentially.
  • The data words: The format of the data words (word length, compression algorithm, sub-sub-event format) is defined by the subEvtDecoding and apart from this it is completely free. The meaning of the data words (detector, geographical position, error information) is defined by the subEvtId and apart from this it is completely unknown to the data acquisition system.

Assigned Numbers

Event Id

The following ranges of evtIds are assigned to the several types:

1-999 Physics: bit[3..0] mirror the LVL2 trigger code from the trigger bus, bit[7..4] mirror the MU trigger info
1500-1999 Slow/Run Control
2000-2999 Simulation
4096-8191 Physics: bit[3..0] mirror the LVL1 trigger code from the trigger bus, bit[7..4] mirror the MU trigger info

For events that resulted from a trigger on the trigger bus, all bits are zero and the least significant bits mirror the trigger code that was indicated by the trigger system.

Additionally, all evtIds may have the MSB set. This indicates an event of the corresponding id that contains broken data (e.g. trigger tag mismatch). Sub Event Id

The following ranges of subEvtIds are assigned to the several groups:
>
>
    • subEvtId - subevent identifier: Tells the analysis the semantics of the subevent data, e.g. every subevent builder may get its own subEvtId. So the data structure can be analyzed by the corresponding routine after unpacking.
 
1-99 DAQ  
100-199 RICH  
200-299 MDC  
Line: 145 to 153
 
900-999 TRB_FW forward wall
1000-1099 TRB_START start detector
1100-1199 TRB_TOF TOF-detector
Deleted:
<
<
  Additionally, all subEvtIds may have the MSB set. This indicates a sub event of the corresponding id that contains broken data (e.g. parity check failed, sub event was too long etc.).
Changed:
<
<

LVL1 trigger code

0x1 (NORM1) physics trigger 1, lowest priority
0x2 (NORM2) physics trigger 2
0x3 (NORM3) physics trigger 3
0x4 (NORM4) physics trigger 4
0x5 (NORM5) Physics Trigger 5
0x6 (SPEC1) not defined yet
0x7 (SPEC2) 0.1Hz offspill
0x8 (SPEC3) not defined yet
0x9 (SPEC4) 10Hz, MDC-calibration
0xa (SPEC5) not defined yet, highest priority

MU trigger info

bit[4] downscaled event flag: if set, event was downscaled
bit[7..5] MU trigger algo result

MU trigger algo result
1 negative decision
2 positive decision
3 positive decision due to too many leptons or dileptons
4 reserved
5 reserved
>
>
    • subEvtTrigNr - subevent Trigger Number: This is the event tag that is produced by the trigger system and is used for checking the correct assembly of several sub entities. In general, this number is not counting sequentially. The lowest significant byte represents the trigger tag generated by the CTU and has to be same for all detector subsystems in one event. The rest is filled by the EB.
  • The data words: The format of the data words (word length, compression algorithm, sub-sub-event format) is defined by the subEvtDecoding and apart from this it is completely free. The meaning of the data words (detector, geographical position, error information) is defined by the subEvtId and apart from this it is completely unknown to the data acquisition system.
 

-- MichaelTraxler - 10 Jan 2006
Revision 4
17 Jul 2008 - Main.MartinJurkovic
Line: 1 to 1
 
META TOPICPARENT name="HadesDaqDocumentation"

HADES raw data format

Line: 48 to 48
 

Event

Changed:
<
<
Events consist out of a fixed size event header and a varying number of variable size subevents.
>
>
Events consist out of a fixed size event header and a varying number of variable size subevents.
 
Changed:
<
<
  • The event header:
>
>

Event header:

 
evtHeader
Changed:
<
<
evtSize evtDecoding evtId evtSeqNr evtDate evtTime evtFileNr evtPad
>
>
evtSize evtDecoding evtId evtSeqNr evtDate evtTime runNr expId
 
Changed:
<
<
  • evtSize - size of the event: This includes the the event header, it is measured in bytes.
>
>
  • evtSize - size of the event: This includes the event header, it is measured in bytes.
 
  • evtDecoding - event decoding type: Tells the analysis the binary format of the event data, so that it can be handed to a corresponding routine for unpacking into a software usable data structure. For easier decoding of this word, the meaning of some bits is already predefined:
    evtDecoding
    msb --- --- lsb
Revision 3
07 Jun 2006 - Main.JoernWuestenfeld
Line: 1 to 1
 
META TOPICPARENT name="HadesDaqDocumentation"

HADES raw data format

Line: 19 to 19
 
  • v1.5 by M. Münch, remove the experiment id, the evtFileNr is not connected to the date any more, minor changes and updates.
  • v1.6 by M. Münch, change in structure, added the appendix for assigned numbers following a discussion about the versioning of the event id
  • v1.7 by M. Traxler, added new subevent ids for TRB-kind-subevents
Added:
>
>
  • v1.8 by J.Wuestenfeld, corrected Subevent Id tables to match
 

project status: current

Line: 120 to 121
  The following ranges of evtIds are assigned to the several types:

1-999 Physics: bit[3..0] mirror the LVL2 trigger code from the trigger bus, bit[7..4] mirror the MU trigger info
Changed:
<
<
1000-1999 Slow/Run Control
>
>
1500-1999 Slow/Run Control
 
2000-2999 Simulation
4096-8191 Physics: bit[3..0] mirror the LVL1 trigger code from the trigger bus, bit[7..4] mirror the MU trigger info
Revision 2
11 Jan 2006 - Main.MichaelTraxler
Line: 1 to 1
 
META TOPICPARENT name="HadesDaqDocumentation"

HADES raw data format

Line: 18 to 18
 
  • v1.4 by M. Münch, define the experiment id, define the error bit in evtid, allow for variable set of sub events in one event
  • v1.5 by M. Münch, remove the experiment id, the evtFileNr is not connected to the date any more, minor changes and updates.
  • v1.6 by M. Münch, change in structure, added the appendix for assigned numbers following a discussion about the versioning of the event id
Added:
>
>
  • v1.7 by M. Traxler, added new subevent ids for TRB-kind-subevents
 

project status: current

Line: 52 to 53
 
evtHeader
evtSize evtDecoding evtId evtSeqNr evtDate evtTime evtFileNr evtPad
Changed:
<
<
  1. evtSize - size of the event: This includes the the event header, it is measured in bytes.
  2. evtDecoding - event decoding type: Tells the analysis the binary format of the event data, so that it can be handed to a corresponding routine for unpacking into a software usable data structure. For easier decoding of this word, the meaning of some bits is already predefined:
>
>
  • evtSize - size of the event: This includes the the event header, it is measured in bytes.
  • evtDecoding - event decoding type: Tells the analysis the binary format of the event data, so that it can be handed to a corresponding routine for unpacking into a software usable data structure. For easier decoding of this word, the meaning of some bits is already predefined:
 
evtDecoding
msb --- --- lsb
Changed:
<
<
0 alignment decoding type
>
>
0 alignment decoding type
 
  1. The first (most significant) byte is always zero.
  2. The second byte contains the alignment of the subevents in the event. 0 = byte, 1 = 16 bit word, 2 = 32 bit word...
  3. The remaining two bytes form the actual decoding type, e.g. fixed length, zero suppressed etc. The last byte must not be zero, so the whole evtDecoding can be used to check for correct or swapped byte order.

It is stated again, that the whole evtDecoding is one 32bit word. The above bit assignments are merely a rule how to select this 32bit numbers.
Changed:
<
<
      1. evtId - event identifier: Tells the analysis the semantics of the event data, e.g. if this is a run start event, data event, simulated event, slow control data, end file event, etc..
      2. evtSeqNr - event number: This is the sequence number of the event in the file. The pair evtFileNr/evtSeqNr is unique throughout all events ever acquired by the system.
      3. evtDate - date of event assembly: evtDate msb --- --- lsb
        1. year month day
          1. The first (most significant) byte is zero
          2. The second byte contains the years since 1900
          3. The third the months since January [0-11]
          4. The last the day of the month [1-31]
>
>
  • evtId - event identifier: Tells the analysis the semantics of the event data, e.g. if this is a run start event, data event, simulated event, slow control data, end file event, etc..
  • evtSeqNr - event number: This is the sequence number of the event in the file. The pair evtFileNr/evtSeqNr is unique throughout all events ever acquired by the system. *evtDate - date of event assembly:
    evtDate
    msb --- --- lsb
    0 year month day
  1. The first (most significant) byte is zero
  2. The second byte contains the years since 1900
  3. The third the months since January [0-11]
  4. The last the day of the month [1-31]
 

(this is the date format of ISO-C)
Changed:
<
<
      1. evtTime - time of assembly: evtTime msb --- --- lsb
        1. hour minute second
          1. The first (most significant) byte is zero
          2. The second byte contains the hours since midnight [0-23]
          3. The third the minutes after the hour [0-59]
          4. The last the seconds after the minute [0-60]
>
>
  • evtTime - time of assembly:
    evtTime
    msb --- --- lsb
    0 hour minute second
  1. The first (most significant) byte is zero
  2. The second byte contains the hours since midnight [0-23]
  3. The third the minutes after the hour [0-59]
  4. The last the seconds after the minute [0-60]
 

(this is the time format of ISO-C)

The date and time field are filled in by the event builder and have thus only rough precision.
Changed:
<
<
      1. evtFileNr - file number: A unique number assigned to the file. The evtFileNr can be used as key to the run database.
      2. evtPad - padding: Makes the event header a multiple of 64 bits long.
>
>
  • evtFileNr - file number: A unique number assigned to the file. The evtFileNr can be used as key to the run database.
  • evtPad - padding: Makes the event header a multiple of 64 bits long.
 
  • The subevents: Every event contains zero to unspecified many subevents. An empty event is allowed, data outside any subevent is not allowed.

Subevent

Line: 96 to 98
  Subevents consist out of a fixed size subevent header and a varying number of data words.

  • The sub event header:
Changed:
<
<
subEvtHeader subEvtSize subEvtDecoding subEvtId subEvtTrigNr
      1. subEvtSize - size of the subevent: This includes the the subevent header, it is measured in bytes.
      2. subEvtDecoding - subevent decoding type: Tells the analysis the binary format of the subevent data, so that it can be handed to a corresponding routine for unpacking into a software usable data structure. For easier decoding of this word, the meaning of some bits is already predefined: subEvtDecoding msb --- --- lsb
        1. data type decoding type
          1. The first (most significant) byte is always zero
          2. The second byte contains the word length of the subevent data. 0 = byte, 1 = 16 bit word, 2 = 32 bit word...
          3. The remaining two bytes form the actual decoding type, e.g. fixed length, zero suppressed etc. The last byte must not be zero, so the whole subEvtDecoding can be used to check for correct or swapped byte order.
>
>
subEvtHeader
subEvtSize subEvtDecoding subEvtId subEvtTrigNr
  1. subEvtSize - size of the subevent: This includes the the subevent header, it is measured in bytes.
  2. subEvtDecoding - subevent decoding type: Tells the analysis the binary format of the subevent data, so that it can be handed to a corresponding routine for unpacking into a software usable data structure. For easier decoding of this word, the meaning of some bits is already predefined:
    subEvtDecoding
    msb --- --- lsb
    0 data type decoding type
    1. The first (most significant) byte is always zero
    2. The second byte contains the word length of the subevent data. 0 = byte, 1 = 16 bit word, 2 = 32 bit word...
    3. The remaining two bytes form the actual decoding type, e.g. fixed length, zero suppressed etc. The last byte must not be zero, so the whole subEvtDecoding can be used to check for correct or swapped byte order.
 

It is stated again, that the whole subEvtDecoding is one 32bit word. The above bit assignments are merely a rule how to select this 32bit numbers.
Changed:
<
<
      1. subEvtId - subevent identifier: Tells the analysis the semantics of the subevent data, e.g. every subevent builder may get its own subEvtId. So the data structure can be analyzed by the corresponding routine after unpacking.
      2. subEvtTrigNr - subevent Trigger Number: This is the event tag that is produced by the trigger system and is used for checking the correct assembly of several sub entities. In general, this number is not counting sequentially.
>
>
  • subEvtId - subevent identifier: Tells the analysis the semantics of the subevent data, e.g. every subevent builder may get its own subEvtId. So the data structure can be analyzed by the corresponding routine after unpacking.
  • subEvtTrigNr - subevent Trigger Number: This is the event tag that is produced by the trigger system and is used for checking the correct assembly of several sub entities. In general, this number is not counting sequentially.
 
  • The data words: The format of the data words (word length, compression algorithm, sub-sub-event format) is defined by the subEvtDecoding and apart from this it is completely free. The meaning of the data words (detector, geographical position, error information) is defined by the subEvtId and apart from this it is completely unknown to the data acquisition system.

Assigned Numbers

Line: 130 to 132
  The following ranges of subEvtIds are assigned to the several groups:
Changed:
<
<
1-99 DAQ
100-199 RICH
200-299 MDC
300-399 SHOWER
400-499 TOF
500-599 TRIG
600-699 SLOW
>
>
1-99 DAQ  
100-199 RICH  
200-299 MDC  
300-399 SHOWER  
400-499 TOF  
500-599 TRIG  
600-699 SLOW  
700-799 TRB_RPC common TRB, but contents is RPC
800-899 TRB_HOD pion-hodoscope
900-999 TRB_FW forward wall
1000-1099 TRB_START start detector
1100-1199 TRB_TOF TOF-detector
 

Additionally, all subEvtIds may have the MSB set. This indicates a sub event of the corresponding id that contains broken data (e.g. parity check failed, sub event was too long etc.).
Changed:
<
<
LVL1 trigger code
>
>

LVL1 trigger code

 

0x1 (NORM1) physics trigger 1, lowest priority
0x2 (NORM2) physics trigger 2
Line: 158 to 166
 
bit[7..5] MU trigger algo result
Changed:
<
<
MU trigger algo result
>
>
MU trigger algo result
 
1 negative decision
2 positive decision
3 positive decision due to too many leptons or dileptons
 
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Hades Wiki? Send feedback
Imprint (in German)
Privacy Policy (in German)