Hall A Analyzer

After some investigation, I conclude that the TI trigger time word is incompatible with the expected data format for a PipeliningModule. To be safe, PipeliningModules must not generate arbitrary payload data words whose topmost bit is set, i.e. (word & (1U<<31)) != 0 because such words might be interpreted as block or event headers or trailers. In reality, the range of ambiguous data values is smaller. The range 0x80-0x97 for the top 8 bits is the danger zone. This range can be even smaller under additional assumptions which may or may not hold. But shrinking the range of disallowed values only reduces the likelihood of a conflict but doesn't fix the underlying problem.

It is easy to fix the decoding of the TI module, as Steve already says, but the bigger question is how much these rogue data words affect the decoding of other modules. At the moment, it looks like things are fairly safe as long as the TI module is in a dedicated CODA bank. This seems to be the case, the crate map (https://github.com/JeffersonLab/hallc_replay/blob/master/MAPS/db_cratemap.dat) has all the TI modules (slot 21), and only those modules, in bank 4.

I'll have to think of a way to make the decoding of PipeliningModule more robust so the TI modules can be decoded reliably, even in multi-block mode. Better yet would be to fix the firmware that writes that ambiguous data word. There's certainly no loss in adding one extra word to these very small (5 or 6 word) TI events.

I have added an experimental check to PipeliningModule::LoadBank that verifies that the number of data words reported in the block trailer agrees with the number of data words implied by the block trailer's position in the buffer, which should always be the case. It seems to work, but I still have to test it further to make sure it causes no unintended trouble. With this check and some extra logic in PipeliningModule, the buffer length given to the TI module decoder should then be correct in single block mode. Not that this is much gain since the TI data can also successfully be decoded in single-block mode with a change in the TI module's decoder (see Steve's hcana commit d42208a).

As for multiblock mode, I think there is no general way this problem can be handled in PipeliningModule. What we can do, however, is to override the LoadBank method in TIBlobModule and use the known data format of the TI events to decode the bank. However, this will still require the TI modules to be in a dedicated bank, which is of course easy to do.

It would help to know how a TI bank would look in multiblock mode. Is the first word after the block header (0xff112001 in the example data above) an event header? So, with time stamp data present, a TI event is 4 words long, including the headers? Hence, if the block size is N, a TI bank would be 2 + 4*N words long (plus possible filler words), where the 2 accounts for block header and block trailer?