A slight reformulation of (ALCT) muonic timing…

1. A slight reformulation of (ALCT) muonic timing… In terms of brass tacks

2. TX1 integer delay tx1 fine delay TX2 integer delay tx2 fine delay S1 cable propagation S2 cable propagation S2 cable propagation rx2 fine delay S1 cable propagation RX2 integer delay rx1 fine delay RX1 integer delay CSC #2 CSC #1 Signal leaving TMB This is a simplified version of Jay’s timing diagram for the BC0 signal propagating from the TMB to the ALCT and back to the TMB for 2 different chambers Signal at ALCT #2  time (bx) Signal at ALCT #1 Signal returning to TMB

3. TX1 integer delay tx1 fine delay TX2 integer delay tx2 fine delay S1 cable propagation S2 cable propagation S2 cable propagation rx2 fine delay S1 cable propagation RX2 integer delay rx1 fine delay RX1 integer delay CSC #2 CSC #1 Signal leaving TMB My understanding of muonic timing is that this time should be constant for all chambers, regardless of txN + TXN Signal at ALCT #2  time (bx) Signal at ALCT #1 Signal returning to TMB

4. TX1 integer delay tx1 fine delay S1 cable propagation S1 cable propagation rx1 fine delay RX1 integer delay CSC #2 CSC #1 Signal leaving TMB TX2 integer delay • TX, tx are (calculated) input values • rx is determined for each value of TX, tx (its value does not matter, it simply makes sure latching happens) • RX is the delay parameter to scan to equalize times from TMB back to TMB for all chambers… tx2 fine delay S2 cable propagation Signal at ALCT #2  time (bx) Signal at ALCT #1 S2 cable propagation rx2 fine delay RX2 integer delay Signal returning to TMB

5. CSC #2 CSC #1 Signal leaving TMB TX1 alct_txd_int_delay tx1 alct_tof_delay TX2 alct_txd_int_delay • TX, tx are (calculated) input values • absorb rx into S2, since that’s its net effect (similar thing for tx_clock_delay) • RX is the delay parameter to scan to equalize times from TMB back to TMB for all chambers… tx2 alct_tof_delay S1 S2 Signal at ALCT #2  time (bx) Signal at ALCT #1 S2 S1 RX2 alct_bx0_delay RX1 alct_bx0_delay Signal returning to TMB

6. CSC #1 Signal leaving TMB TX1 alct_txd_int_delay • To define T… • Use the feature that TMB has TWO BC0 signals • CLCT_BC0 (local to TMB) • ALCT_BC0 (takes the path on the left) •  There is an xml parameter called tmb_bxn_offset which sets the value of CLCT_BC0 when TMB receives the BC0 signal from CCB… • When ALCT_BC0 and CLCT_BC0 are synchronized at the bottom of the page, then… • 3564 – tmb_bxn_offset = T • (3563 is the maximum value of BXN) tx1 alct_tof_delay S1  time (bx) T Signal at ALCT #1 S1 RX1 alct_bx0_delay Signal returning to TMB

7. Scan over input delays for a given T With clct_bx0_delay = 15 With tmb_bxn_offset = 3550 Scanning from 0 to 16 alct_txd_int_delay[0] = 0 alct_txd_int_delay[1] = 0 alct_txd_int_delay[2] = 0 alct_txd_int_delay[3] = 0 alct_txd_int_delay[4] = 0 alct_txd_int_delay[5] = 0 alct_txd_int_delay[6] = 0 alct_txd_int_delay[7] = 0 alct_txd_int_delay[8] = 0 alct_txd_int_delay[9] = 0 alct_txd_int_delay[10] = 0 alct_txd_int_delay[11] = 0 alct_txd_int_delay[12] = 0 alct_txd_int_delay[13] = 0 alct_txd_int_delay[14] = 100 alct_txd_int_delay[15] = 0  Best value is alct_txd_int_delay = 14 This is just to prove that such a scan can be done at 904. The actual scan should scan over alct_bx0_delay. In addition, I would argue that clct_bx0_delay is never needed (given tmb_bxn_offset)

8. Muonic Timing-in Procedure - Main Steps • Get good communication with ALCT • Leave TOF delays at current, “arbitrary” values. Or perhaps 0? • Align all of the BC0’s returning from ALCTs • Implement calculated TOF delays for ALCTs • Implement calculated TOF delays for CLCTs and establish good CFEBTMB data transmission • Check ALCT-CLCT time matching • This should work, regardless of CSC data source (cosmics, beam, etc.) • Check SP alignment of LCTs (“Dayong” procedure) • This will check out perfectly if the TOF delays have been properly calculated given the exact trigger conditions (From Jay’s talk last week…)

9. Muonic Timing-in Procedure - Main Steps with ALCT • For ALL chambers set • alct_tof_delay=0 • alct_txdata_int_delay=0 • tmb_bxn_offset = value such that the shortest TMB-ALCT cable requires alct_bx0_delay=15 • Get good TMB  ALCT communication • Determine alct_[rx,tx]_clock_delay, alct_[rx,tx]_posneg • Align all of the BC0’s returning from ALCTs • Determine alct_bx0_delay to set T • Implement calculated TOF delays for ALCTs • Remeasure 2. and 3., preserving T

10. Essential differences between muonic timing and current timing (1) • Currently: afeb_fine_delay used for sub-bx timing changes in trigger data • These values should go back to FAST site values (i.e., to correct for different AFEB-ALCT cable delays) • Currently: mpc_tx_delay used for bx timing changes in trigger data • These values should go to 0 for all TMB’s

11. Essential differences between muonic timing and current timing (2) • Currently: match_trig_alct_delay (alct_delay) = 8 for all TMB’s • These values must change corresponding to the changes in alct_bx0_delay. This is needed to keep ALCT data in sync with ALCT_BC0… • match_trig_alct_delay delays all ALCT data except ALCT_BC0 • alct_bx0_delay delays ALCT_BC0

12. Essential differences between muonic timing and current timing (3) • What if the alignment of LCTs from different chambers for the same muon is wrong at the SP (“Dayong’s” procedure)? We will need to… • Implement the negative correction in alct_tof_delay • Redo the communication and BC0 alignment for this chamber BC0 signals are always synchronized all the way to the SP by construction… What will happen to the BXN attached to this muon? Will it be off by the same amount? In other words, will a distribution of absolute bxn give the same result as Dayong’s procedure?

13. ALCT BXN at the ALCT At the moment, at the ALCT… • The timing of ALCT_BC0 is fixed • There is a parameter alct_bxn_offset, but it only affects the bxn labeling of the data  The data for the muon whose trigger info is labeled with ALCT_BC0 and sent to TMB has BXN=alct_bxn_offset I believe this is not the right thing to do. I asked Alex and Lev if they didn’t think it should be done with an offset (e.g., as it is done in TMB)  No answer yet… But actually, thinking about it more, I think it might be better done with a BC0 offset implemented in the TTCci Thoughts?

14. To do • Put in the code for ALCT as on page 9 • Think about CFEB muonic timing • This is the critical path for the muon trigger latency, do we want to add delay to this path? It might not matter as long as we don’t add delay to the whole system…