If an L1A comes within 2 bunches after receiving a BC0 it would have
been cancelled (not sent to VFATs) in previous versions, but now the BC0
gets cancelled instead. In this case, a flag will get set for 1 orbit in
ec_bc field indicating that (more on this below).
Also in this version the EC_BC FIFO is cleared after receiving a TTC
resync command.
EC_BC field consisted of a 12bit wide BC and a 20bit wide EC. In this
version the EC gets shortened to 16bits, and the 4 spare bits in the
middle are used as follows:
bit 19: If this is set to 1, it means that OH EC/BC FIFO is empty for
this event (OH EC/BC underflow). This is an anomaly, which might be
caused by VFATs sending more data than the number of L1As that they were
sent, or it could be related to resync handling in OH where the OH
clears it's EC/BC buffer before reading out all VFAT data. I don't
expect this to happen often or at all, but if it does happen it would be
very useful to know that. In case this is set to 1, the BC will always
be set to 0xfff, and the EC will be a fake one, but guaranteed to be a
different number each time so that the AMC can still separate these
events.
bit 18: this bit is latched to 1 whenever the above mentioned condition
happens, and cleared only during the next resync. I would call this bit
OH had EC/BC underflow
bit 17: this bit is latched to 1 if the OH ever had EC/BC fifo overflow,
and is cleared by a resync (which also clears this fifo). If overflow
ever happens, it will result in OH EC/BC going out of sync with the AMC.
This can happen if VFATs are missing some L1As.
bit 16: this bit is latched to 1 whenever a BC0 is canceled by an L1A,
and this flag is cleared when the next BC0 arrives. During the time when
this bit is set to 1, the VFAT BC is going to be wrong due to the missed
BC0, but can be corrected by subtracting 3564 from the reported VFAT BC
with a rollover (that is if VFAT BC - 3564 is e.g. equal to -2, that
means the real VFAT BC is 0xfff - 3564 + 2