We were running in anyHitMode and expandedMode and we started a histogram scanning from 0 to 31 bits of the TX_DELAY variable in steps of 3 (full mode). In the 3rd bin, the ROD went busy and stopped the triggers by going busy. Here is the ROD dump from this:
/work/srsctdaq1/sr1daq/scratch/Dump_01538_00000
From StandardDumpFRM?.bin (from emacs hexl-mode so bytes need swapping):
00001800: 0f07 0f07 ff0f ff0f 0000 0000 0000 0000 ................ 00001810: ff00 ff00 ff0f ff0f c001 c001 f001 f001 ................ 00001820: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00001830: 0000 0000 0000 0000 0000 0000 f000 f000 ................ 00001840 - 00001860 00001870: 0000 0000 0000 0000 0f07 0f07 0000 0000 ................ 00001880: ff0f ff0f 6083 0000 200e 0000 0000 0020 ....`... ...... 00001890 - 00001af0
This is the block of registers associated with formatter 6 (where the modules are attached).
0x70f on the 6th line say header trailer limit err on all links. The 0x0 after that says not ROD busy... strange.
Here is the data:
/work/srsctdaq1/sr1daq/saved_data/SctData::RawScanResult.2526.0.*.gz
and
/work/srsctdaq1/sr1daq/saved_data/TestData.2526.0.PhysicsModeTimingScan?.gz
This test was done with 4 modules from the H8Testbox -- they have higher occupancy from the barrel modules, btw...
For the CrateServer? log, look at:
/home/sr1daq/SctApiCrateServer?0_ctatsct01_srsctdaq1.cern.ch_19669_17.out
The bytestream for this run is at
/data/sct/daq_SCTEB__0002526_file01.writing
There are no errors at the tail of this bytestream.