Hall A Analyzer

h1. Decoder

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

h2. 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.

<pre>

==== 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

</pre>

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.

h2. For   PROGRAMMERS

If you find yourself needing to understand how the code works, here is a "Class diagram":http://hallaweb.jlab.org/podd/doc/decoder_class.pdf for the decoder. The main public interface is @THaEvData@.

Here is a cookbook list of things to do to [[Add VME Module|add a new module]].