Overview | Releases | Download | Docs | Links | Help | RecentChanges

HistogrammingProblemsInPhysicsMode

While trying to run the ( version 1.1.2.5 of ) physicsModeTimingScan.java in TDAQ14_BRANCH under SctApiIPC?/scripts, we have ROD problems. Here is an example...

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.