SPIDER Testbeam meeting 16/06/2009

Present D. Cussans (Bristol), J. Wilson (Birmingham),  P. Dauncey (Imperial), 
J. Crooks, J. Strube , M. Stanitzki (RAL)

Minutes: Marcel

Picking up on the actions from last week, we haven't heard from Rui yet, 
whether he has successfuly compiled the TPAc firmware. Dave mentioned, that 
the last time they soke, there where still issues with the XiLinx libraries.

ACTION Dave: Check with Rui about the status

John and Dave had an exchange concerning whether to use the Birmingham board 
or the TLU. Both can do the job, the advantage of the TLU is, that it is 
available, but it als requires an USB connection for programming it. Dave also 
added that it is the size of a shoe-box and besides USB it only needs a 5V 
supply. The main worry where the signal levels out of the PMT. Dave added that 
it worked for most of the PMT's he encountered, but John pointed out the 
levels are very low. We decided to go for the Birmingham solution and have the 
TLU as a backup. John said, Birmingham can get going on these and have them 
soon, as the design is almost done. Paul raised the question, whether we'd 
like TTL or LVDS. Dave and Marcel suggested to make both available, since that 
is is rather standard to do.
  
ACTION Dave: follow up with Rui, understand which inputs are possible right now, TTL, LVDS, etc.
ACTION John & Paul: Check feasibility of LVDS and TTL outputs

Paul has been in contact with Matt and pointed out, that the Master USBDAQ 
could use a separate Firmware. This would make the Master firmware easier. We 
would then operate in the same fashion as at DESY, where we had only the PMT's 
connected to the Master. Paul pointed out, that we then need to keep track of 
USBDAQ firmware versions and be able to flash them in-situ. Marcel and Jamie 
pointed out, that they have been flashing USBDAQ's on a regular basis using 
the JTAG. Dave added , that speaking to Matt, there is also the option of 
downloading the firmware via USB, but we agreed that the JTAG is proven and 
reliable and we can easily take a cable along.

Dave then reported on the Fortis DAQ. He has the chain from the Fortis frames 
on Disk in the EUDET DAQ working. The EUDET uses and "Standard Event format" 
and once the FORTIS frames have been converted, all the EUDET tools are 
available,. so we can check hits and alignment online,e.g. What is not working 
is reading out the Fortis and writing events to disk. The command-line tool 
isn't ready as yet, waiting for input from Rob Halsall. Also Bristol hasn't 
managed to read-out the Fortis yet using the GUI. Jamie commented on the wrong 
software and firmware versions being used up to now, but Dave added, that 
they've fixed it and it still doesn't work.

ACTION Dave, Jamie: Get the Fortis readout going and sort out the remaining issue

Coming back to the TPAC DAQ, one point raised by PAul is the distribution of 
clock signals. Dave said, that CALICE has a Clock Fanout board using LVDS, 
which might be used, but everyone agreedd, that the USBDAQ master would be the 
much better choice to distribute clock signal. Also we need to have the 
appropriate connectors for the fanout (and also the PMT inputs)

ACTION Paul: specify connectors for clock fanout and pmt inputs
ACTION Paul: Contact Matt Warren to see if the CALICE board is an option.

For the testbeam we plan to take 2 Fortis "stacks" and two FPGA board with us. 
Marcel mentioned, that he and renato went ahead ordering three more from Aspect.
Jamie pointed out, that the length of the Microcoax Cables is an issue and 
should be looked into for the beam test. Jamie said, that longest cable is 
about 1 meter. He'll see how many spares are available in what length and 
report next meeting. Ideally we'd like to take at least 2 cables along

ACTION Jamie: Report on Microcoax cable availability 

There was some discussion on whether to go with Fortis 1.0 or Fortis 1.1 to 
the testbeam. Given that Fortis 1.1 also comes in high-res and with a deep 
p-well, it would of course be the chip of choice to go. But we'd keep Fortis 
1.0 as a backup. Given that they are pin-compatible, this should be 
transparent down to the configuration file level. There was the question on 
how much time we'd actually need per variant. Dave reported that last year 
they had about 1000 tracks per cm2 per second, so for the size of one Fortis 
unit, that is about 10 tracks per second. Marcel estimated, that about 10000 
tracks are sufficient to get a decent landau, so this would be 3 hours per 
variant. If however we want to go down to mapping chips, this get much more 
difficult. An estimate by Marcel was about 15 hours. Jaap has made some more 
detailed studies and he'll report the next time. Dave also mentioned that Jaap 
is thinking on not vetoing the trigger to accumulate more stats, so there 
would be one Fortis frame with 30 EUDET frames associated.

Paul reported on the TPAC progess saying that all the chips he trimemd so far 
(3) work fine and we can also now do threshold scans with all the pixels 
online, something which we couldn't do with TPAC 1.0. He sees some odd noise, 
which seems to be external as it is not reproducible. Paul reminded Marcel and 
Dave about the USB cards for the PC's. We are not so much worried about total 
bandwidth as we'll be limited by disk speed anyway

ACTION Marcel: Order 4 USB cards (PCI))

Next Meeting 23/06/2009 1100