Testbeam setup



TDC investigation (Spiroc 2e feature)

THe SPIROC 2e has a know problem, that the TDC value jumps by 27~33 ns depending on the stopping condition.

New firmware with a different acquisition timing and different condition to stop is at retiming branch in the desy svn. (TODO link)

Quick test of problem existence

I picked a run # 66390 - run with absorber, >300000 evts, hitting mostly channel 8.

file processing:

#on EUDAQ PC in /mnt/hdd3/analysis/Run66390
for p in 1 2 3 ; do 
	for m in 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 ; do 
		echo "correlating p${p} m${m}" ;
		~/AHCAL-RAWutils/ahcalBifCorrelation/ahcalbifcorrelate \
			-w /mnt/hdd1/AhcalRaw/ahcalRaw_Run066390__18p05p2019__15p19p20.raw \
			-t -1 \
			-r 67380 \
			-b /mnt/hdd1/BifRaw/bifraw-run066390__18p05p2019__15p19p20.raw \
			-h \
			-c 8 \
			-m ${m} \
			--lda_port=${p} \
#this creates a lot of txt files: corr_L*_c8_m*.txt

Quick plotting in gnuplot:

#in gnuplot:
	set yrange [0:4095]
	set xrange [0:5120]
	#first plot:
	plot 'corr_L3_c8_m0.txt' u 10:6 w d

	#Second plot:
	plot 'corr_L3_c8_m15.txt' u 10:6 w d

(click to ziim the pictures)

bad for memory cells 0..14 (they can be stopped externally):

The only OK memory cell is 15, because that fills the ASIC and then it stops by itself:

New DIF firmware:


BIF: 19019 (yes, much different!)

LDA: 589

It seems, that the hypothesis on stopping BXID parity  was correct. Red: run 66394 (even bxid), blue:66393 (odd bxid):

ILC mode with new firmware

stopping at even bxid

LDA offset 285

BIF offset 9290

Run data quality check

BIF statistics summary

It seems, that something went wrong with the BIF - it was slipping a clock cycle quite often.

Some clock phase changes are to be expected (restarting the CCC), some are unexpected.

Run number vs. timestamp (color is the start_acquisition phase):

Bif offsets varying a bit (position?): 67397. (67381~67405)

LDA statistics summary:

  • No labels