ALCTTMB loopback Dealt with char bug with CERN

ALCT-TMB loopback Dealt with “char” bug with CERN software limiting TMB register value to only 0 xff… Teven/Todd: Teven/Todd: Teven/Todd: Teven/Todd: ddd_delay= 0 ddd_delay= 1 ddd_delay= 2 ddd_delay= 3 ddd_delay= 4 ddd_delay= 5 ddd_delay= 6 ddd_delay= 7 ddd_delay= 8 ddd_delay= 9 ddd_delay=10 ddd_delay=11 ddd_delay=12 4 Mar 2009 rxdata_1 st=05555555 rxdata_1 st=05151510 rxdata_1 st=0 AA 8 AAAA rxdata_1 st=0 AAAAAAA rxdata_1 st=0 AAAA 2 A 8 rxdata_1 st=00531455 rxdata_1 st=05555555 rxdata_2 nd=0 AAAAAAA rxdata_2 nd=0 AAA 2008 rxdata_2 nd=05515555 rxdata_2 nd=05555555 rxdata_2 nd=05555511 rxdata_2 nd=00048822 rxdata_2 nd=0 AAAAAAA G. Rakness (UCLA) 1 st_err/latched=1/1 1 st_err/latched=0/0 1 st_err/latched=1/1 1 st_err/latched=1/1 2 nd_err=1/1 2 nd_err=0/0 2 nd_err=1/1 2 nd_err=1/1 Now this column of information is correct… 1

Recall: Old firmware, old ALCT rx/tx scan (at 904) With ALCT in “Send Empty mode”, step in matrix of rx, tx: count the number of data words latched by TMB Result (tx vs. rx) tx ----> 00 01 02 03 04 05 06 07 08 09 10 11 12 ==== ==== ==== ==== rx = 0 0 0 0 0 3 d 8 0 0 rx = 1 0 0 0 0 rx = 2 0 0 0 0 rx = 3 0 0 0 0 rx = 4 0 0 0 3 d 8 0 0 0 0 0 rx = 5 0 0 0 3 d 8 0 0 0 0 rx = 6 0 0 0 3 d 8 0 0 0 0 rx = 7 0 0 0 3 d 8 0 0 0 rx = 8 0 0 0 3 d 8 3 d 8 0 0 0 rx = 9 0 0 0 3 d 8 0 0 rx =10 0 0 3 d 8 0 0 rx =11 0 0 0 3 d 8 0 0 rx =12 0 0 0 0 3 d 8 0 0 Best value is alct_rx_clock_delay = 8 Best value is alct_tx_clock_delay = 5 Recall: Last week, the new ALCT firmware was ½-cycle different from this ALCT firmware… 4 Mar 2009 G. Rakness (UCLA) 2

With new ALCT firmware… --> Summed over all data pairs: alct_tx bad data count -----------0 28000 1 28000 2 28000 3 2000 4 0 5 0 6 0 7 0 8 6524 9 26979 a 28000 b 28000 c 28000 Best value is alct_tx_clock_delay = 6 4 Mar 2009 G. Rakness (UCLA) 3

For each wire pair ------------------------Cable Pair Errors vs alct_tx_clock_Delay ------------------------delay 0 1 2 3 4 5 6 7 8 9 10 pair ---- ---- ---- ---0 1000 0 0 948 1000 1000 0 0 1000 2 1000 0 0 1000 3 1000 0 0 0 1000 4 1000 0 0 0 1000 5 1000 0 0 0 1000 6 1000 0 0 1000 7 1000 0 0 195 1000 8 1000 0 0 0 1000 9 1000 1000 0 0 0 1000 11 1000 0 0 999 1000 12 1000 0 0 0 1000 13 1000 0 0 0 1000 14 1000 0 0 127 1000 15 1000 0 0 619 1000 16 1000 0 0 0 1000 17 1000 0 0 0 1000 18 1000 0 0 0 979 1000 1000 0 0 0 1000 20 1000 0 0 0 1000 21 1000 0 0 0 1000 22 1000 0 0 636 1000 23 1000 0 0 0 1000 24 1000 0 0 0 1000 25 1000 0 0 0 1000 26 1000 0 0 0 1000 27 1000 0 0 1000 4 Mar 2009 G. Rakness 0(UCLA) 11 ---1000 1000 1000 1000 1000 1000 1000 12 ---1000 1000 1000 1000 1000 1000 1000 Everybody plugged in OK… 4

Alct_rx_scan --> Summed over all data pairs: This scan: alct_rx bad data count -----------1. Set alct_tx_clock_delay = 6 (from 0 0 previous page) 1 0 2. Put ALCT in “loopback” mode 2 2823 3 10000 3. Step through alct_rx_clock_delay 4 10880 4. Send the following from TMB 5 20000 ALCT to receive back at TMB: 6 20000 7 20000 • 0 x 2 AA in 1 st frame 8 20000 • 0 x 155 in 2 nd frame 9 10000 a 10000 b 99 c 0 Best value is alct_rx_clock_delay = 0 Previous values = (rx, tx) = (8, 5) 4 Mar 2009 New values = (rx, tx) = (0, 6) G. Rakness (UCLA) Is this difference a concern? 5

Rx scan for each wire pair ------------------------Cable Pair Errors vs alct_rx_clock_Delay ------------------------delay 0 1 2 3 4 5 6 7 pair ---- ---- ---0 0 0 282 1000 1000 1 0 0 282 1000 1000 2 0 0 284 1000 1000 3 0 0 282 1000 1000 4 0 0 282 1000 1000 5 0 0 282 1000 1000 6 0 0 283 1000 1000 7 0 0 282 1000 1000 8 0 0 282 1000 1000 9 0 0 282 1000 1000 10 0 0 98 1000 11 0 0 106 1000 12 0 0 85 1000 13 0 0 98 1000 14 0 0 90 1000 15 0 0 98 1000 16 0 0 67 1000 17 0 0 77 1000 18 0 0 83 1000 19 0 0 78 1000 20 0 0 0 0 21 0 0 0 0 22 0 0 0 0 23 0 0 0 0 24 0 0 0 0 25 0 0 0 0 26 0 0 0 0 27 0 0 0 0 4 Mar 2009 8 ---1000 1000 1000 1000 1000 0 0 0 0 9 ---1000 1000 1000 0 0 0 0 10 11 12 ---- ---1000 0 0 1000 99 0 1000 0 0 1000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 G. Rakness (UCLA) “Good communication window” is… • Narrow for all pairs • Widens for other pairs • Wide open for other pairs Do I have a bug? 6

CANbus progress Major progress thanks to “Handshake” program (E. Juska [FNAL]) • Maraton: “permanent” communication failures – Requires power-cycle of Maraton to re-establish communication – Seen on several (>5) Maratons each night for over a week – Disappeared with CANbus firmware update from 2. 16 2. 18 • ELMB: impedance mismatch found on cable carrying CANbus signals and power – Using 28 AWG cable over ~300 m “extra” 100 on line – Decision made to buy cable with more copper • ELMB: discovered that version of CANbus driver that we were using was 3 years old, with 13 upgrades in the meantime… – To be updated on Friday evening, run handshake program over the weekend on both chains… • Remaining problems – Grounding on Maraton chain not as it should be – ELMB grounding scheme under investigation, but problematic due to the introduction of ground loops into the system Genuine hope that CANbus problems will go away in 20097 G. Rakness (UCLA) 4 Mar 2009

Other stuff • Mid-Week Global Run began today – – Just got started, had trouble getting Global Trigger going… Confirmed Global L 1 A Latency is equal to CRAFT (November 2008) Data runs not yet going… I am shift leader Thursday shift • Apparently RPC Endcaps Link. Board firmware was run with “unknown” delay values in CRAFT… This is to be fixed in a MWGR soon… – I will push them on this topic next MWGR (25 – 26 March) • Luca and Paul at Rice are running the CSCValidation package to assess where CSC’s stand with regards to the amount of the system which is working – Most problems on ME – 2 and ME – 3 (where we haven’t had access to, yet…) • I am giving no talks at the EMu meeting during CMS week – Bora Akgun (CMU) is giving the Commissioning talk – Bob Clare (UC-Riverside) is giving the DCS talk – Karoly Banicz (FNAL) is giving the Online Software talk • While debugging CFEB problems in endcaps, Misha asked if it would be possible to have CLCT pretrigger counters for each 4 Mar 2009 G. Rakness (UCLA) CFEB? 8

To do • Continue with the rest of the TMB + ALCT test firmware/software at CERN – at 904 – At point 5 on chambers with problems • Combine firmware version check into configuration check moving towards a single push-button check of all configuration • Make firmware reloading an automated procedure… 4 Mar 2009 G. Rakness (UCLA) 9