I am still not sure that this is correct: orbitFirstSampled is the orbit from which the sampling starts, the actual 1st orbit seen in the collision-context might be > orbitFirstSampled. I think one should use HBFUtils::Instance().getFirstSampledTFIR().orbit instead, since this will give the 1st orbit of the TF where the digitization starts.
Could you run e.g. with HBFUtils.orbitFirst=13700;HBFUtils.orbitFirstSampled=13800
to avoid the situation were the orbitFirstSampled and HBFUtils::Instance().getFirstSampledTFIR().orbit coincide?

Yes, I will test it (thanks also for the explanation, I didn't get the difference between the two options)

orbitFirstSampled -> firsts orbit in digits 13800
getFirstSampledTFIR -> first orbit in digits 13700

So I guess the second one is correct.

In any case in our digitization we are using orbitFirstSampled to start to fill the timeframe (I didn't test the original digitization here), Shell I change also it there?

I mean here:
void Digitizer::init()
{

// set first readout window in MC production getting
mReadoutWindowCurrent = o2::raw::HBFUtils::Instance().orbitFirstSampled * Geo::NWINDOW_IN_ORBIT;

Not sure since the digitization does not know about TFs.
What is the exact meaning of the mReadoutWindowCurrent?
The orbitFirstSampled can be anywhere within the TF, it is just an internal hint to the IR sample from which orbit to start (and the real 1st interaction orbit will be likely > orbitFirstSampled).
As such, this is the smallest orbit you may encounter in the collision context.

we start to fill digits from this mReadoutWindowCurrent (/orbit)
All digits occuring before are discarded.
This is used to avoid the creation of readout window starting from 0 (a very large overhead if orbitFirstSampled is large).
We cannot accept digit in an infinite time range because we need to define the TOF readout structure starting from a reasonable time start.

Then it should be ok, since you are guaranteed not to have interactions before the orbitFirstSampled

Good. PR is ready now