Draft: Walk correction for cbm::algo::UnpackSts.

An attempt to implement walk correction coefficients into cbm::algo::UnpackSts to the best of my knowledge.

Here is my understanding of the situation:

Walk coefficients are supplied in tables, stored in files such as macro/beamtime/mcbm2021/mStsAsicTimeWalk.par, which contains lines such as the following:

0x10008002      0       -24.343851      2.794827        -0.103235       0.001478
0x10008002      1       -24.453138      2.485316        -0.084344       0.001143
0x10008002      2       -21.335244      2.585311        -0.094605       0.001301
0x10008002      3       -27.042286      3.172233        -0.124657       0.001763
...
0x10008002      13      -17.299280      2.451026        -0.100094       0.001467
0x10008002      14      -19.148061      2.444700        -0.094107       0.001301
0x10008002      15      -27.609664      2.979764        -0.118827       0.001815
0x10008402      0       -16.073344      2.122262        -0.077667       0.001089
0x10008402      1       -14.128047      1.925380        -0.068603       0.000927
0x10008402      2       -14.816346      2.138562        -0.086058       0.001264
...

The first column stores the "module address". The second the "asic in module", which loops over the values [0:15]. The remaining entries are contents of a std::vector, of which the index is the the ADC value minus one.

So in other words, for each ASIC we have such a correction vector. The coefficients are additively applied to the time-stamp of digis, and are selected according to the ADC value of the digi.

This seems rather straight-forward in principle. Unfortunately, I have so far not been able to bit-wise reproduce the output of the legacy unpacker with cbm::algo::UnpackSts. This in part may be due to the following: The macro I am using reads the walk correction coefficients with the lines

 // Time Walk correction
    std::map<uint32_t, CbmStsParModule> walkMap;
    auto parAsic = new CbmStsParAsic(128, 31, 31., 1., 5., 800., 1000., 3.9789e-3);

    // Module params: number of channels, number of channels per ASIC
    auto parMod = new CbmStsParModule(2048, 128);

    // default
    double p0 = 0, p1 = 0, p2 = 0, p3 = 0;
    parAsic->SetWalkCoef({p0, p1, p2, p3});
    parMod->SetAllAsics(*parAsic);

    walkMap[0x10107C02] = CbmStsParModule(*parMod);  // Make a copy for storage
    walkMap[0x101FFC02] = CbmStsParModule(*parMod);  // Make a copy for storage

    /// To be replaced by a storage in a new parameter class later
    int sensor, asic;
    std::ifstream asicTimeWalk_par(Form("%s/mStsAsicTimeWalk.par", parfilesbasepathSts.data()));
    while (asicTimeWalk_par >> std::hex >> sensor >> std::dec >> asic >> p0 >> p1 >> p2 >> p3) {
      // std::cout << Form("Setting time-walk parameters for: module %x, ASIC %u\n", sensor, asic);
      parAsic->SetWalkCoef({p0, p1, p2, p3});

      if (walkMap.find(sensor) == walkMap.end()) { walkMap[sensor] = CbmStsParModule(*parMod); }
      walkMap[sensor].SetAsic(asic, *parAsic);
      // std::cout << Form("Done with time-walk parameters for: module %x, ASIC %u\n", sensor, asic);
    }

    stsconfig->SetWalkMap(walkMap);
    walkMap.clear();

So there is some magic happening here with the walk map, that goes beyond reading it from the file. Maybe @a.toia or @p.-a.loizeau can comment on what is going on here. Are the contents of the map in the end different from what is in mStsAsicTimeWalk.par?

Also, I should add that the corrections are very small numbers compared to the timestamp itself, that typically affect that last one or two digits only. So in a bit-wise comparison, it seems to be possible to mix them up with rounding errors. Also, vectors of walk coefficients in principle can have up to 31 (I believe) entries in the original class, but this particular file only has four entries.

@v.friese @p.-a.loizeau @a.toia Any input is appreciated here. Am I basically on the right track?

Also @fweig : I'm again using hard-coded numbers and working with the legacy config class for now. Presumably it is not hard to include this feature into the YAML-based system.