This describes the decoding of raw data used by the Root/C++ analyzer as of version 1.6.
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.
If you find yourself needing to understand how the code works, here is a Class diagram for the decoder. The main public interface is
Here is a cookbook list of things to do to add a new module.
Updated by Ole Hansen about 5 years ago · 1 revisions