Decoder¶

This describes the decoding of raw data used by the Root/C++ analyzer as of version 1.6.

For USERS¶

From a User perspective, the main thing to control the decoding is the db_cratemap.dat file. This file should be set up by the DAQ expert and should contain the full list of modules deployed, whether they are used by detectors or not. The format of db_cratemap.dat is probably best learned by example, see below. Having a mistake in this file can lead to empty histograms or complaints from Podd. Podd will print out the cratemap, so you can confirm that you have the correct one.

==== Crate 4 type fastbus
# slot  model   clear   header  mask    nchan   ndata
   9    1877    1       0x0     0x0     96      672
  13    1877    1       0x0     0x0     96      672
  18    1875    1       0x0     0x0     64      512
  21    1881    1       0x0     0x0     64      64

==== Crate 9 type vme Header Decoding
# slot    model    clear    header    mask    nchan    ndata
  10     250     1      0xfb0b0b0b 0xffffffff  16  10000

==== Crate 10 type vme Bank Decoding
# slot  model   bank
  3     250     3

In the above example there is a Fastbus crate number 4, and two VME crates, nums 9 and 10. A "crate number" is synonymous with a "CODA ROC number". In crate 4, there are 4 slots occupied with the models shown (1877, 1875, or 1881) and you can usually leave header and mask zero, but for VME modules they may be nonzero. For some DAQ systems the beginning of the slot is marked by a "header word", e.g. 0xfb0b0b0b for the module in slot 10 of crate 9. For other systems, all the data of a module is put into a "CODA bank", as in the decoding for crate 10 above.

For PROGRAMMERS¶

If you find yourself needing to understand how the code works, here is a Class diagram for the decoder. The main public interface is THaEvData.

Here is a cookbook list of things to do to add a new module.