Support for CROB-wise time offset for BMON unpacker.

Feature requested in https://redmine.cbm.gsi.de/issues/3336.

Requires updates to yaml files (to be submitted soon).

Builds upon !1850 (merged)

requested review from @p.-a.loizeau

assigned to @p.-a.loizeau

changed the description

mentioned in merge request CbmSoft/cbmroot_parameter!193 (merged)

added Online Parameters mCBM labels

added 9 commits

• 312deb63...4f075fca - 6 commits from branch computing:master
• 130f3282 - Switched from hard-coded parameters to YAML-based parameters for TOF unpacker in cbm::algo.
• 6571ddfc - Switched from hard-coded parameters to YAML-based parameters for TOF unpacker in cbm::algo.
• cadd0596 - Added support for CROB-wise time offset to BMON unpacker parameters.

Compare with previous version

added 4 commits

• cadd0596...a70f3389 - 3 commits from branch computing:master
• b5578b49 - Added support for CROB-wise time offset to BMON unpacker parameters.

Compare with previous version

added 1 commit

• 10f9cd4e - Added support for CROB-wise time offset to BMON unpacker parameters.

Compare with previous version

@p.-a.loizeau It just occured to me, that the offset is not necessarily unsigned. Changed this.

resolved all threads

added 1 commit

• 823c0976 - Bump parameters hash to bring BMON online unpacker offsets (mostly in new one)

Compare with previous version

approved this merge request

enabled an automatic merge when the pipeline for 823c0976 succeeds

@n.herrmann @a.toia This brings the time offset correction for the new BMon on the "online unpacker" side with the following effect.
I will try to make a corresponding change to the legacy unpacker and parameters tomorrow, but I do not promise anything as it may conflict due to the dual use for both TOF and BMON (especially the parameter side).

Time difference between Old and new Diamond when offset is 0 for all

---

Time difference between Old and new Diamond when offset is 0 for Old and 12 ns for New
=> There remain a split in 2 peaks separated by ~2-3 ns but it comes from the position, and as we change channel in both diamond we cannot decide whether it comes from a specific channel. Probably will be corrected by walk correction and is anyway good enough for event building and reference of other detectors

Dear @d.smith, @fweig, @f.uhlig,

you have been identified as code owner of at least one file which was changed with this merge request.

Please check the changes and approve them or request changes.

added CodeOwners label

merged