Skip to content

Sts unpack 2391 / bugfix for 1588

Dominik Smith requested to merge d.smith/cbmroot:StsUnpack2391 into master

The purpose of this MR is to eventually creata a proper .yaml file with parameters for the STS unpacker for run 2391.

Upon starting my attempt to do so, I discovered an irregularity which should be addressed first.

The following is the block describing the module addresses from the macro/beamtime/mcbm2021/mStsPar.par file, which was originally used to set the hardcoded parameters of cbm::algo::UnpackSts

ModAddress: Int_t \
  0x10008002      0x10018002 \
  0x10008402      0x10018402    0x10107C02 \
  0x10008412      0x10018412    0x101FFC02 \
  0x10008012      0x10018012    0x10008812      0x10018812      0x10028812

The following are the corresponding lines from StsReadoutConfigLegacy::Init():

 // Module addresses (CbmStsAddress)
    int32_t modAddress[numModules];
    modAddress[0]  = 0x10008002;
    modAddress[1]  = 0x10018002;
    modAddress[2]  = 0x10008402;
    modAddress[3]  = 0x10018402;
    modAddress[4]  = 0x10107C02;
    modAddress[5]  = 0x10008412;
    modAddress[6]  = 0x10018412;
    modAddress[7]  = 0x101FFC02;
    modAddress[8]  = 0x10008812;
    modAddress[9]  = 0x10018812;
    modAddress[10] = 0x10028812;
    modAddress[11] = 0x10008012;
    modAddress[12] = 0x10018012;

What can be seen here, is that one can read the upper block line-by-line from left to right and find the corresponding address in the lower block, until one reaches the last line. The last line then has a strange permutation applied to it, whereby the first two addresses are actually assigned to modules 11 and 12, instead of modules 8 and 9, as one would expect. This is potentially problematic, as the module number is then used to assign several other parameters. The problem carries over to the file algo/params/StsReadout.yaml, which was derived from StsReadoutConfigLegacy.

So it is likely that some of the addresses of digis are wrong in the output. This should not however affect time and ADC values.

The reason why this was not discovered earlier, is likely due to the address/time/charge compression that is applied in the CbmStsDigi class. When looking at TBrowser histograms for the different fields of the STS digis everything, strangely, seems to match exactly between the original and the algo version of the unpacker. However, the field fAddress, which one would expect to contain the module address, due to compression, doesn't actually contain this number. The stored addresses are actually several orders of magnitude smaller. Currently, there doesn't seem to be a way to access the true address from TBrowser.

Since I wasn't involved in the creation of the original hardcoded tables, and also have close to no knowledge of the packing procedure, I wonder if someone else could shed some light on the issue. Perhaps there is some subtle detail that I'm missing, and the above addresses are indeed the correct ones for some reason.

@a.toia @fweig @p.-a.loizeau @v.friese

Merge request reports