As you may know, the SPS schedule slipped a week, and the beam test users schedule was recently updated. You can find the latest schedule from here:
http://sps-schedule.web.cern.ch/sps-schedule/
The 25 ns run has slipped a week to June 14 - 21. However, the start of the asynchronous period for the CSC tests in x5a has not changed, and is scheduled to begin May 17. What has changed is that we now have 3 weeks of asynchronous beam until June 8.
Thus, we should aim to be be ready about the same time as before. Chambers should be moved and flushing started before this May 17 date. Several of us from the U.S. will be there a week ahead of time to re-assemble the system from Florida with computers and electronics.
It looks like our summer at x5a is getting longer, but at least we have more time to achieve our goals. I'll put together a web site soon with links to information.
If you plan to participate, please send Jay Roberts and I your schedule so we know.
From acosta@phys.ufl.edu Fri May 7 12:02:01 2004
Date: Tue, 04 May 2004 09:32:20 -0400 (EDT)
From: "Darin Acosta "
Subject: CSC TB2004 web page
I started a web page for the CSC testbeam 2004 activities:
http://www.phys.ufl.edu/~acosta/tb/tb.html
Among other things, it has an equipment manifest for items that need to be shipped from the U.S. to CERN. Please take a look and see if you have the items I requested (or if you have other needs). Rice, UCLA, OSU in particular should check. I also listed people's schedules at CERN as I know them, and there is a preliminary task list for pre-beam activities. (We still need to work out the detailed testbeam activities and order).
The UF cosmic ray stand is being de-commissioned TODAY so that items can be shipped out. If this is a problem let me know immediately.
We were not able to complete the SP check-out with the latest data format at UF, and thus neither could we try event-building. This will take place later this month at CERN.
Date: Fri, 7 May 2004 12:29:34 -0400 (EDT)
From: "Darin Acosta "
Subject: CSC beam test news
This is just an update on the CSC beam test. The UF cosmic ray stand was packed up and shipped Wednesday, 5/5/04. The 3 DMB's we had and the DDU were sent to OSU and have been received. See the equipment manifest on the web page to see what was sent, and what is expected still be shipped or carried and when.
The Dubna group finished building their ME1/1 support stand and have moved it to x5a. Yong Wook also completed the ME1/2 stand as well (see photo on the beam test web page). The HV and LV system will be monitored over tcp/ip by PVSS during the beam test! The RPC group looks to be in some trouble for making the June test. I'll learn more later.
On Tuesday at CERN at 16:00, there will be a beam test users meeting. I will attend for CSC. On Wednesday next week, we will have a CSC beam test meeting at CERN (the ISR area) at 9:30am for those of us here to discuss the plan for moving chambers and equipment to x5a.
Date: Mon, 10 May 2004 23:00:56 +0200 (CEST)
From: Ian Crotty
Subject: Re: RE1/2 progress
Today we ( Mr Chai and Jun ) put all 8 screws in to the modified brackets and so by mounted an empty production RE1/2 onto ME1/2 sn 008. Tomorrow we will mount it with insulating screws. This contradicts a discussion I had with Sergei Lusin but seems to be sensible as it leaves our options open trying to avoid ground loops.
The only complete chamber we have now has stopped its Khz of noise and will go into the cosmic stand tomorrow. We will see, it looks Ok.
Ian
On Tue, 11 May 2004, Darin Acosta wrote:
At the testbeam users meeting today it was confirmed by Pino that the barrel RPC group is not ready for a beam test this June. They would like to test with DT in September at H2 (along with HCAL), but if that is unlikely they prefer to remain at the GIF for their tests.
However, encouraging information from Grzegorz Wrochna regarding the status of RPC electronics tests is found here. So far, we still have the possibility of doing an integration test between CSC and RPC electronics at x5a using an endcap RPC chamber!
Beam is still planned for Monday, May 17. We must get certified before our test by filling out a safety form and possibly having our setup inspected.
On Wed, 12 May 2004, Darin Acosta wrote:
All VME crates and boxes shipped from the UF cosmic ray stand have arrived at CERN. Andrea, Holger, Jay, and Frank also arrived yesterday. We now have a core team.
Transportation of chambers, crates, electronics and computers to X5A started today. As can be seen, the ME1/1 chamber was installed into its stand in the beam area. The two DAQ PC's also were set up and are alive. A new Track-Finder backplane with DT connectors was installed into the Track-Finder crate today by Alexei. The crane operators lifted 2 racks onto the balcony today (we have 4 total), but the rest of the CSC chambers are scheduled for tomorrow at 8am.
We have a safety inspection slated for next Tuesday morning.
Jay Roberts' warning for all of us: "Do not give wrong advice."
On Thu, 13 May 2004, Darin Acosta wrote:
All 4 CSC chambers have been installed into X5A, as can be seen above. There is even a movie taken by Lindsey showing the installation using the crane. The cables from the two peripheral crates to the computers and Track-Finder crate have been installed, but the HV, LV, and skew-clear cables from the chambers to peripheral crates on the balcony still need to be installed.
On Fri, 14 May 2004, Darin Acosta wrote:
The four CSC chambers are coming alive. The ISR FAST site team is running a suite of tests to verify that the chambers are working properly, and to measure the HV plateau. In their tests, they already see beam muons coming into the area! In fact, the area coordinator increased the rate for us. Cables for 3 of the 4 chambers (all but ME1/1) were installed onto the cable trays, but will not be attached to the chambers until the ISR team has certified the chambers.
Some technical news: The TTCmi crate does not distribute a clock during the asynchronous period. We have to run with the "Lev clock patch" for 40.08 MHz operation. We ran a PRBS test between the MPC and SP in the TF crate, no link errors over 1 hour.
On Fri, 14 May 2004, Frank Geurts wrote:
Both acosta1.cern.ch and geurts1.cern.ch are now online and accessible from within the CERN network. To get to them from outside CERN use some gateway machine like lxplus.cern.ch. Accounts and passwords have not changed, same thing for access to the Florida repository.
On Sat, 15 May 2004, Darin Acosta wrote:
Three chambers have been checked out by the ISR team: ME1/2, ME2/2, and ME3/2. They are now cabled up to the peripheral crate (see picture), and HV is now on to ME2/2 and ME3/2. We are waiting for beam before we can try any timing-in procedures. ALCT firmware has been downloaded into ME2/2 and ME3/2.
On Mon, 17 May 2004, Darin Acosta wrote:
All chambers are ready to deliver data, including ME1/1. Most of yesterday and today was spent bringing the DAQ system alive. Some timing-in procedures have been applied to ME2/2 and ME3/2 (CFEB and TMB), but of course the ALCT timing has not been tuned for efficiency until we get the data logging and analysis working.
The HV system is switched to the PVSS controlled CAEN system, supported by Xiaofeng Yang. ME1/1 is at 3.0 kV, all the rest at 3.5 kV. ALCT firmware has been downloaded into all chambers. The set for ME1/1 has a new ghost-busting feature.
With Lev and Victor here, we are now trying to bring the Track-Finder into the system. Lots of progress on the official first day of the run.
More advice: People should not play contact sports during a beam test (or roller blade for that matter).
On Tue, 18 May 2004, Darin Acosta wrote:
We passed the safety inspection this morning with only a few suggestions to implement. We needed to clear out some old ladders, get the 220V cord to ME1/1 off the floor, and label HV to the PMTs.
The biggest news is that we are getting closer to data. The system is slowly getting timed-in. We've seen data logged through the DDU, and data has gone down the pipe all the way to the Track-Finder! In fact, the spy FIFO on the Track-Finder shows a 16 bx structure in the LCTs, which is an indication of the LCT deadtime. What is being worked on now by Martin et al. is the timing in of the TMB data. The efficiency of getting data for a given L1A is very low right now.
Valery Sytnik reports that he has ported the DCS software to the geurts1 PC, which is running Redhat 9. Moreover, he adapted his software for the new CCB and TMB 2004 designs. He can monitor temperatures, voltages, etc. However, we cannot simultaneously record DCS data and regular DAQ data. That's because the DCS system configures the crate differently than PeripheralCrateController. Given that we are urgently trying to log good data, we have postponed the integration of DCS with the Run Control until next week, where a common initialization will be implemented. But it is a big success that we have PVSS monitoring our data.
In another minor breakthrough, Lindsey and Andrea (with consultation with Greg P.) figured out how to program the TTCvi FIFOs so that every spill we have the "start trigger" and "stop trigger" sequence needed by the firmware on all boards.
By the way, in each spill, we have about 17K triggers.
On Wed, 19 May 2004, Darin Acosta wrote:
Data is finally being logged by the new data acquisition system! We have two chambers in the readout, ME2/2 and ME3/2. Efficiency has gotten better, but is not great yet. Here is the output of the UCLA trigger primitive analysis program for 3600 events:
Chamber 0 #events with no ALCT = 202 #events total = 3400 eff = 0.940588
Chamber 1 #events with no ALCT = 696 #events total = 3400 eff = 0.795294
Chamber 0 #events with no CLCT = 793 #events total = 3400 eff = 0.766765
Chamber 1 #events with no CLCT = 1269 #events total = 3400 eff = 0.626765
Chamber 0 #events with no digi ALCT = 202 #events total = 3400 eff = 0.940588
Chamber 1 #events with no digi ALCT = 700 #events total = 3400 eff = 0.794118
Chamber 0 #events with no digi CLCT = 1673 #events total = 3400 eff = 0.507941
Chamber 1 #events with no digi CLCT = 2056 #events total = 3400 eff = 0.395294
max1 = 2404 max2 = 899 max1+max2 = 3303 sum = 3344 ratio = 0.7189
max1 = 2261 max2 = 447 max1+max2 = 2708 sum = 2841 ratio = 0.795847
Plots for runs will be kept in the "plots" subdirectory of this web area.
Unfortunately, after some code updates to make the data quality improve, the beam was lost. Current status shows a 12 hour delay. Thus, the experts above have taken a well-deserved break.
On Fri, 21 May 2004, Darin Acosta wrote:
Unfortunately, the SPS down time has developed into a long delay, wth beam "unlikely before Sunday". You can check on the SPS status here. This came at a bad time, because we just had a glimpse of data on Wednesday, but we still need to do the ALCT timing-scan to complete the system set up. In the mean time, the Track-Finder group is injecting fake data into the MPC to check out the new firmware and software, and also is developing firmware to test a new DT/CSC transition card (which doesn't require beam).
No updates posted yesterday because I was on a plane flying back to Florida. I return to CERN June 4. Let's hope beam returns before more electronics experts leave next week.
On Sun, 23 May 2004, Darin Acosta wrote:
PS and SPS troubles continue. See the message here . Beam won't return to X5 until Monday. The good news is that we don't have to wait as long as for the North area.
On Mon, 24 May 2004, Darin Acosta wrote:
For a summary of beam test activities today, see Martin's report below.
Over the last few days while there was no beam, the Track-Finder group successfully tested the second version of the DT/CSC transition card using a loopback test (i.e. no DT Track-Finder). Lev's summary is here.
On Tue, 25 May 2004, Martin von der Mey wrote:
Hi guys,
I was a little too tired to write a summary yesterday but here it comes.
-Today we won't have been until 4:00 pm.
-Yesterday we were reading out two chambers and got
the efficiencies over 90% for the CLCTs and ALCTs.
-The main problem we have is that the rate seems too
high. The SCAs were getting full and putting 'b'-codes
in the data stream. This corrupted the readout and
also
reduced the efficiency a lot.
-Jay introduced a timeout to reduce the number of L1s
-With this change the b-codes went down but still are
there. At some point at the beginning yesterday Jason
was getting around 100 kHz of LCTs on one CFEB. (Too
much). So I increased the thresholds on the TMBs
pre-trigger to DiStrip=7/HalfStrip=4/Pattern=1. This
helped a little bit but since we had real muons the
rate was still too high.
-Jay H. pointed out that the digi efficiency for the
CLCTs is lower than the one directly coming from the
TMB triggering. As we think it is due to the b-code
problem. Jianhui is looking into this and promised to
email a solution today.
-Yesterday I started with the ALCT scan for the two
chambers but stopped then since I think we should get
first the three chambers in the readout before doing
all kind of scans. (Since they are simultanously).
-So I will readout events with 3 chambers tonight.
-The guys from Dubna moved today the cables for ME1/1
from one of the crates to the one that has our 3
TMBs/DMBs. They are asking for reading out the ME1/1
chambers also. I would rather get the 3 chamber
readout working and then maybe include the ME1/1.
-Then as I understand even with 2 chambers the sector
processor has synchronisation problems. So, lets see
tonight with 3.
p.s
Another thing that we did and I forgot to mention, the
DMB had new firmware loaded that was sampling 16
timesamples of CFEB data. Last year it was using 8
samples. This was also a reason for "timeouts" on the
CFEBs.
So, we loaded the (testbeam) old firmware to all the
CFEBs for the two chambers. The one used before with 8
timesamples.
This reduced the deadtime but maybe had some bug in
there that was fixed in the new firmare. (the bugs
that Jianhui is checking).
On Tue, 25 May 2004, Darin Acosta wrote:
Lots going on. I just append everything from e-mail:
From mey@physics.ucla.edu Wed May 26 13:07:25 2004
all data with run number > 42 are now with 3 chambers. Jason M. is trying to get his program working on this data.
only runs 42 and 43 seems good. The previous ones are bad.
From bslock@phys.ufl.edu Wed May 26 13:07:43 2004
I just thought I'd give you a little update now that we actually have
beam. Martin installed a third chamber, and seems to have timed it in
properly. Looking at the Spy Fifos, Lindsey and I were able to determine
the bx on which most LCTs occur, then set the CCB04 L1A delay register to
pull back the LCTs to within the 0-7bx window for the DDU output. This
seems to have worked, and we can now get data. Just for fun, I plotted
some interesting distributions from a single spill, since I can now point
and click my way through data in the root file. If you go to:
http://www.phys.ufl.edu/~bslock/testbeam04/
(1) HalfStripPlot.gif shows the Halfstrip numbers for CSCID 8 (in gray),
CSCID 3 centered about 100, and CSCID 1 centered about 80.
As I understand, CSCIDs 1,3, and 8 are ME1/2, ME2/2, and ME3/2.
(2) Quality.gif shows quality for CSCID 1 in red, 3 in black, and 8 in
gray.
(3) TimePic.gif shows the number of LCTs which occur on a given bx
w.r.t. the L1A. The x-axis shows which bx number. bx=0 is when the L1A
occurs. We only have a 7 bx window for the DDU output. CSCID 1 is shown in
red, 3 in black, and 8 in gray.
We're a bit concerned about the offset for CSCID 8 in this last plot. This offset combined with the large spread in quality values for 8 seems to suggest that chamber is not well timed - at least, that's what Martin says. Anyway, Lindsey seems to have successfully implemented the run control signals from the TTC, and we can take data with these signals on. Once again, the L1A limit for the SP to overflow seems to be about 3000 L1As/spill. We'll start taking simultaneous PC and TFC data soon.
From bslock@phys.ufl.edu Wed May 26 13:07:51 2004
Martin and I made a first attempt at taking data from both crates. He said you know where to find the DDU data. It's run 48. I put the SP ascii file in /home/daq/testbeam04. Right now it's the only file in there. It was only a 2 minutes run.
From mey@physics.ucla.edu Wed May 26 13:08:01 2004
we took an ALCT delay scan synchronized with the whole system. The runs are :
Run# delay
50 10
51 15
52 20
55 30
56 5
57 0
From mvondermey@yahoo.com Wed May 26 13:08:19 2004
Subject: CFEBs
I just put new firmware that Jinahui sent to all CFEBs and took a run=58. I already sent him an email. I hope this fixes the b-code problem. In the meantime i am finishing the ALCT scan....
From mey@physics.ucla.edu Wed May 26 13:08:27 2004
Subject: ALCT scan
I continued with the ALCT scan. Here are the runs and ALCT delays. Please have a look. Tomorrow I will continue. This data is for 3 chambers....
Run#/delay
49/10
50/10
51/15
52/20
53/25
54/25
55/30
56/5
57/0
59/2
60/7
61/12
62/17
63/22
64/27
On Wed, 26 May 2004, Martin von der May wrote:
I just timed in ME1/1 and put it in the readout. I hope your programs are ready for 4 chambers.:) After lunch I will start to take some data.
From mey@physics.ucla.edu Wed May 26 13:08:48 2004
I just took some 4 chambes runs=66 and 67. Please have a look when you get a chance.
On Sat, 29 May 2004, Darin Acosta wrote:
There has been a lot of e-mail traffic in the last several days as the group struggles to get the system to reliably record good data through the DDU readout. Unfortunately, this is still not fully resolved. Anyway, trying to keep up with that has caused my news postings to stop for a while.
But lets review some of our accomplishments of the last several
days. First of all, the Sector Processor (aka Track-Finder) has been
successful in its ability to log data independently or concurrently with
the DDU read out. A timing scan of the ALCT delay was performed
for runs 72-78 (ALCT delay 0 - 30 ns in 5 ns steps), and the SP logged
data simultaneously with the DDU. Unfortunately only runs 77 and 78
appear to have decent DDU data. Some plots of the BX time distribution
of the LCTs for various ALCT delays are available for all 4 chambers
(
CSC3,
CSC8,
CSC1,
CSC10).
A different view of the same efficiency data as a function of the ALCT
delay for a given BX is also available
(
CSC3,
CSC8,
CSC1,
CSC10). What is not understood is why the data does not just
smootly shift from one BX to the next as the delay is increased. It
tends to snap back to a previous case. A property of the asynchronous
beam? However, it is actually fortunate that the CSC data is
distributed on different BXs. That's because for a given BX, the MPC
sorts and truncates the data to just 3 LCTs! But since the data is
usually not all on one LCT, all 4 chambers are seen by the SP!
By the way, the efficiency for the SP to see each chamber for run 77
is:
CSC3: 0.986869 CSC8: 0.969728 CSC1: 0.969758 CSC10: 0.758065
Another thing that was done was to compare the LCT data received by the SP with what was sent by the MPC and logged by the DDU DAQ system. Since the MPC is not read out, a program first takes the TMB data and runs it through the MPC simulation before comparing to the SP input data. This checks the integrity of the optical data transmission (a source of frustration last year without a PLL), as well as the integrity of the two DAQ systems and data unpacking programs. Remarkably, at this early stage, we can already demonstrate ~97% perfect agreement (in 2000 events) between the LCT frames received by the SP and those sent by the TMB/DDU for runs 77 and 78. The differences that remain seem to be mostly data missing in the TMB/DDU readout when the LCT is has shifted by about 2 BX from its usual position, but there are other reasons as well.
Other news:
I've started archiving the data to CASTOR:
/castor/cern.ch/user/t/tbx5ccdr/tb2004/
Use "rfdir" and "rfcp" for a directory listing and to copy, respectively.
The Dubna group made a survey of the chamber positions. See this document.
On Sun, 30 May 2004, Darin Acosta wrote:
A number of runs were taken last night and today using only the Track-Finder readout to log data in order to study the performance of the ALCT firmware for a variety of settings. The Track-Finder readout is currently independent of the DDU (and thus not subject to the difficulties we are having). The main object of study was the ALCT ghost rate (probability to record more than one LCT when only one muon is present).
Prelimary results on the efficiency and ghost rate are available here. Preliminary conclusions and questions are here. Note that it is assumed that just one muon crossed the chambers for this quick study. The data should be cleaned up to ensure only one muon indeed went through the chambers.
On Tues, 8 June 2004, Darin Acosta wrote:
As you can see from the date, I missed a whole week of updates! That actually means good news. We solved our data logging issues and have been taking "good" data since middle of last week. Lots of runs taken. Achievements include:
On Thursday this week the RPC groups will be installing RE1/2. Waraw group will come Thursday and Friday and start installing electronics.
Documentation on runs taken with different ALCT settings and logged simultaneously by the DDU and Track-Finder is here: [PDF, XLS]
