what have i been up to?

14 Jan 2009 G. Rakness (UCLA) 1

What have I been up to?• RAT analysis

– Will show the results at RPC Detector Performance Group meeting 27 Jan.

• Workshop at Rice: “CSC System Overview”– ALCT fuse blowing is a concern– Figured out a way to Power-on the system cleanly

• Wrote first drafts for CSC Quarterly Report– Electronics Commissioning now in F.

Borcherding’s hands…– Shift structure now in R. Breedon’s hands…


RE+1/2 pad-bit mapping


Recall ALCT key wiregroup vs. CLCT key ½-strip:

heuristic RPC pad-bit mapping for ME+1/3

CLCT key ½-strip ()

ALC

T k

ey w

iregr

oup

() 01 3 2

5 64 7

9 108 11

ME+1/3 data


ALCT key wiregroup vs. CLCT key ½-strip for ME+1/2:

RPC pad bit = 0


ALC

T k

ey w

iregr

oup

()

ME+1/2 even chamber number

REVERSED Local-(x,y) position as ME+1/3

ME+1/2 odd chamber number

SAME Local-(x,y) position as ME+1/3



RPC pad bit = 1


ALC

T k

ey w

iregr

oup

()







RPC pad bit = 2


ALC

T k

ey w

iregr

oup

()







RPC pad bit = 3


ALC

T k

ey w

iregr

oup

()






“Theoretical” RPC Pad Bit Mapping Compared with CSC data


Conventions of RPC rolls and strips corresponding to CSC ALCT wiregroups

and CLCT ½-strips

• Local-y (r, [, ]):

• RPC: 3 “Rolls” each covering a length LN

• CSC: ALCT key wiregroup

• Local-x:

• RPC: 32 strips per Roll; 1 pad bit = “OR” of 8 strips

• CSC: CLCT key ½-strip

A

B

C

LA

LB

LC

Increasing CLCT key ½-strip

Increasing ALCT key wiregroup

y

x


“Theoretical” Assumptions

A

B

C

LA

LB

LC

Ring 2 (cm)

Ring 2 (wiregroups)

Ring 3 (cm)

Ring 3 (wiregroups)

LA 53.5 18.8 40.3 7.5

LB 49.0 17.2 75.9 14

LC 79.4 28 56.0 10.5

Increasing CLCT key ½-strip

Increasing ALCT key wiregroup

Assume no offsets and equal active areas of CSC and RPC—this would be “Ideal”

• ALCT wiregroup 0 Bottom of Roll C

• ALCT wiregroup 32 (ME1/3) or 64 (ME1/2) Top of Roll A

• CLCT ½-strip 0 Left edge of Rolls A, B, and C

• CLCT ½-strip 128 (ME1/3) or 160 (ME1/2) Right edge of Rolls A, B, and C

(LN numbers from C. Carrillo [U. de

Los Andes])


RE+1/2: Data vs. geometrical expectations

The red lines are the boundaries expected from RE+1/2 Roll geometry assuming equal and overlapping active areas…

The data are approximately consistent with these assumptions


RE+1/2: Data vs. Geometrical Expectations The data are approximately consistent with expectations


RE+1/3: Data vs. geometrical expectations

The red lines are the boundaries expected from RE+1/3 Roll geometry assuming equal and overlapping active areas…

The data are not consistent with this assumption

Where are the active areas of the RPC endcap?


RE+1/3: Data vs. Geometrical Expectations Where are the active areas of the RPC endcap?


Summary of RPC data in RAT• Good correlation seen between CSC trigger primitive

position and RPC Endcap data– See reversal of even RE+1/2 chambers, as expected– RE+1/3 pad-bit maps well onto CSC active area– Modification of RE+1/3 pad bit mapping in the RPC Link Board

will be needed to optimize “ghostbusting” for CSC trigger primitives

– Given that RPC roll geometry cannot be corrected with the Link Board, I believe this mapping will have to go into TMB…

• Recall: RPC Endcap data are late relative to the CSC trigger primitive– RPC Link Board data needs to be faster in order to be useful for

CSC trigger primitives Link Board thinks they have only 3.5 – 4.5 bx latency… (M. Konecki, Warsaw)

– How much of this is coming from cable lengths?• D. Loveless said that there are several meters of excess cable

length...


ALCT Blowing FusesDiscovery in Feb. 2008: Loading the incorrect firmware

type to ALCT can cause an on-chamber fuse to blow

• April 2008: the software to load ALCT firmware was upgraded to include hard-coded checks on:

– xml parameters (slot, chamber label, ALCT type)– hardware (readback of PROM ID codes, crate controller ID)

• N.B. Still need to include “verify” when programming ALCT PROM to ensure the program is correct before it is loaded to the FPGA

… Even with this fix, fuses were continuing to blow at a (low) rate…

But… recall that this is not the first occurrence of

blowing fuses…


Preliminary Discussion on Blowing Fuses

19 November 2007

Present: F. Borcherding, M. Ignatenko, F. Geurts, S. Golyach, G. Rakness

Goal: To make a plan of action regarding blowing fuses on board ALCT

Recall: ~no fuses blew in all FAST site tests…

(Note: summary of discussion at workshop January 2009: no solid ideas of what could be causing fuses to blow…)


How close to the blowing current are we?Fuses on both ALCT and LVDB are 5A

• Currents drawn by ALCT (values measured at 904 with 28 Aug 2008 firmware version):

• 3.3V 3.3A for FPGA communication (2/3 of fuse rating)

• 1.8V 1.9A for FPGA core (40% of fuse rating)

• 5.5V_1 2.6/0.1 A with AFEBs ON/OFF

• 5.5V_2 2.6/0.1 A with AFEBs ON/OFF

At UCLA, it was pointed out to me that…

1. These numbers are uncomfortably close inductance effects could easily push over the threshold

2. It would be interesting to measure these values at large trigger rates

3. In the FPGA, an input line being changed to an output line (e.g., resulting from a single corrupted bit) could cause this problem…


What is the ideal power-up scenario?

Recall, we have already been developing a power-up procedure during 2008…

Is it complete?

A controlled power up of the “Final Destination” (i.e., Chamber or Peripheral Crate) would require the following steps. First, for the Peripheral Crate…

1. Voltage Control Board power ON

2. Voltage Control Board disable output power to the Final Destination

3. Power source to the Final Destination ON

4. Voltage Control Board enable output power to the Final Destination

Next, perform steps 1 – 4 for the Chamber…


CSC LV Control DistributionPower Source Voltage Distribution Final Destination

Voltage Control Boards

Maraton

Voltage Control Power Source

Atlas PCMB

Peripheral Crate

Chamber

DMB LVMB

LVDB

CRBMaraton

Current power-up sequence features:• Atlas power supply + PCMB control independence allows the Peripheral Crate to be

powered up in the “Ideal” way…• However, we currently power on ALL Maraton channels when powering on the

peripheral crate Step 3 is achieved before 1 and 2 for the Chambers…• Furthermore, since the default state of the LVMB is to enable output voltage when

the DMB is powered on, steps 1 and 2 are coupled to 4 for the Chambers…

“Ideal” power-up condition is NOT achieved for the Chambers


Modification of Power-On Procedures

1. DCS “Disable peripheral crate monitoring”– Stops VME reads while powering on components (step 2)– Avoid “colliding packets” between csc-dcs-pc[1,2] and csc-pc[1,2] (steps 3-6)

2. Set digital and analog lines to 0V– This “turns off” power to the chamber

3. Power on Maratons4. Turn on Peripheral crates with PCMB (as in the “normal” power-up sequence... causes the following to

happen serially to each peripheral crate– enable power to 1.5V… pause 150ms– For (TMB/DMB pair 1 to 9)

• enable TMB/DMB… pause 150ms [TMB LEDs on (not flashing), DMB lower two LEDs on]– additional pause 150ms– enable Crate Controller (VCC)… pause 100ms [VCC “FPGA ready” LED on] – enable MPC/CCB [TMB's and DMB's FPGAs loaded]

5. “Check crate controllers” – reads VCC FPGA version and checks that the VCC can communicate with CCB

6. Peripheral Crate Initialization– CCB hard reset to load FPGA’s to Peripheral Crate electronics

7. Turn off Chambers from LVDB (through DMB)8. Set digital and analog lines to 7.5V

– This enables voltage to the chambers

9. Finish the Crate Power-up Init– Power ON chambers, CCB hard reset, configure TTCrq, put MPC in serializer mode

10. TTCci configure1. Sends “broadcast 0” to all TTCrq for final configuration (to correctly decode BGo commands)

• “Check Crates Configuration”1. Read and check configuration of TMB, ALCT, DMB, CFEB, MPC, CCB

• DCS “Enable peripheral crate monitoring”

Items in red are updates to the procedure from October 2008 in order to power-up the chambers in the “ideal” way…


To do

• Test power-up procedure on one trigger sector in ME+1– Measure voltage vs. time with oscilloscope at

power-on– Measure current vs. time (?)

• Attempt to measure time-of-flight in beam-halo or CRAFT data…

what have i been up to?

Documents