1. Collaboration Meeting April 27-29, 2004 Pixel Testbeam Update D. Christian, D. Menasce, C. Newsom, M. Turqueti, L. Uplegger, J. Wang, D. Zhang

2. Collaboration Meeting April 27-29, 2004 Pixel Testbeam Update Data Flow Schematics PC FPIX… Read Out Chip PMC PTA

3. Collaboration Meeting April 27-29, 2004 Pixel Testbeam Update Data Flow Schematics PC 30 meters cables

4. Collaboration Meeting April 27-29, 2004 Pixel Testbeam Update Timing overview Events are built using the time-stamp information provided by the pixel planes. The read-out is data driven and we don’t need the the trigger information provided by the scintillators placed upstream and downstream. It must be guaranteed that all the planes receive the same BCO clock and that it is reset for all at the same time. The mezzanine firmware has been designed to provide a BCO clock and a reset which is synchronous to all planes.

5. Collaboration Meeting April 27-29, 2004 Pixel Testbeam Update Synchronization Mechanism Master SlavesMaster Clock & BCO Reset Accelerator radiofrequency

6. Collaboration Meeting April 27-29, 2004 Pixel Testbeam Update Problems So far we could test the system, during the DAQ phase development, by injecting charge in FEW pixel cells; with this strategy we didn’t found evidence of timing problem. Usually problems were mainly due to the reliability of the cables that connect the PMC and detectors. We know they are very critical, once in place we avoid touching them.

7. Collaboration Meeting April 27-29, 2004 Pixel Testbeam Update Three weeks ago we were finally ready to take data since the beam was made available at MTEST!!!! We immediately found BCO synchronization problems in one of the 3 PMC installed during preliminary tests but we thought that those problems were related again to faulty cables that were corrupting the data, so we decided to run with only 4 of the 6 pixel planes installed! 4 working plane data with very preliminary beam profile are shown in the following pictures: First day results 04/02/04

8. Collaboration Meeting April 27-29, 2004 Pixel Testbeam Update Beam First day results 04/02/04

9. Collaboration Meeting April 27-29, 2004 Pixel Testbeam Update Run 405 04/02/04 ?! Row ID = 63  When match with another plane we see secondary coincidence line.  We re-check the row-column plot and found the magic number 63, strongly suggested a cable problem. First day results 04/02/04

10. Collaboration Meeting April 27-29, 2004 Pixel Testbeam Update Run 661, 04/09/04 Beam is tuned to center on the first two planes.

11. Collaboration Meeting April 27-29, 2004 Pixel Testbeam Update Clear coincidence between the first two planes. Only X direction is shown. The 1 st plane uses column to measures X, and the 2 nd plane uses row. The geometry alignment between two planes is done by offline software. Run 661, 04/09/04

12. Collaboration Meeting April 27-29, 2004 Pixel Testbeam Update Where is the problem? There were many clues suggesting that all these problems were due or to faulty cables or to data corruption generated by the mezzanine card. We finally discovered that both problems were present. If the first one can be solved by checking all the cables and being very careful not to touch them after installation, the second requires a more sophisticated solution. After many attempts to find a patch for the mezzanine firmware that allows us to take data with all six installed planes the only solution that seems to work so far, is to slow down the read-out and BCO clocks from 16 and 8 MHz respectively to 4 and 2 MHz.

13. Collaboration Meeting April 27-29, 2004 Pixel Testbeam Update Mezzanine Firmware The firmware is implemented with a correct logic but it doesn’t correctly implement the rules of the trade that MUST be followed to obtain a reliably working FPGA. The present mezzanine firmware generates clocks using internal flip-flops which can accumulate delays when propagating signals through the device providing different time latches with different data lines. In any case, slowing down the clocks seems to have solved the problem for now but we need to do some more tests in order to be sure. We will do these tests in the following days while waiting to get some beam.

14. Collaboration Meeting April 27-29, 2004 Pixel Testbeam Update Summary and conclusion We were successfully able to take data for the first time with new new DAQ. Using the beam we discovered the latch problem discussed previously. The DAQ software worked as expected and only marginal modifications must be applied. The 6 FPIX1 pixel planes are working very well at the frequencies required by BTeV. ~8 MHz (~130ns period) for the BCO clock ~16 MHz for the read-out clock.

15. Collaboration Meeting April 27-29, 2004 Pixel Testbeam Update Unfortunately we couldn’t fully test the BCO synchronization mechanism between different cards because data and BCO were corrupted as I explained. Now, with a slower clock rate we should no longer be plagued by latching problems, and this will allow us to fully test the event builder and, hopefully, get some reconstructed tracks. Summary and conclusion

16. Collaboration Meeting April 27-29, 2004 Pixel Testbeam Update Summary and conclusion In the next weeks we will be working to develop the firmware for the FPIX2 to be tested in the beam, taking into account the experience gained with FPIX1. In this new firmware version we plan to implement all the Mandatory rules foreseen for internal clock handling. In the mean time, as soon as the beam will be available again, we will work to align the installed FPIX1’s, we will check the BCO synchronization and the two event building algorithms we developed with multiple cards installed.

17. Collaboration Meeting April 27-29, 2004 Pixel Testbeam Update Orsay the pixel test-beam event display

18. Collaboration Meeting April 27-29, 2004 Pixel Testbeam Update Pixel test-beam data will be available in two formats: 1.raw data 2.reconstructed data We need a tool to visualize these data and help debug both DAQ and reconstruction related problems. I developed a rudimentary event-display to represent these data in a 3D space, rotate and manipulate both the detector, the hits and the reconstructed tracks. Additionally users can pick elements like hits, detector planes or tracks and get information about them like hit number, track parameters (slope, intercept,  2 …)

19. Collaboration Meeting April 27-29, 2004 Pixel Testbeam Update I evaluated options available in the Open Source, public domain: VRML (Virtual Reality Modeling Language): pro: excellent 3D capabilities very good rendering (hidden lines removal of solids) con: rather complex no easy to use program interface (slow start) no support for pick and choose VRML (Virtual Reality Modeling Language): pro: excellent 3D capabilities very good rendering (hidden lines removal of solids) con: rather complex no easy to use program interface (slow start) no support for pick and choose wired (a SLAC project by Joseph Perl) pro: light-weight user programming interface (quick start) support for pick and choose (most useful feature) specialized for the HEP environment con: only wire-frame limited 3D rendering capabilities difficult interpretation of picture when too crowded by hits/tracks wired (a SLAC project by Joseph Perl) pro: light-weight user programming interface (quick start) support for pick and choose (most useful feature) specialized for the HEP environment con: only wire-frame limited 3D rendering capabilities difficult interpretation of picture when too crowded by hits/tracks

20. Collaboration Meeting April 27-29, 2004 Pixel Testbeam Update Input to wired are XML files with HepRep syntax

21. Collaboration Meeting April 27-29, 2004 Pixel Testbeam Update Raw data Binary Rec. data ASCII xml Orsay Orsay: raw/rec converter to xml (wired input)

22. Collaboration Meeting April 27-29, 2004 Pixel Testbeam Update

23. Collaboration Meeting April 27-29, 2004 Pixel Testbeam Update Front view & parallel projection by default

24. Collaboration Meeting April 27-29, 2004 Pixel Testbeam Update

25. Collaboration Meeting April 27-29, 2004 Pixel Testbeam Update Mouse movements direct rotation/translation/zooming of current picture

26. Collaboration Meeting April 27-29, 2004 Pixel Testbeam Update Right button click pops-up a menu to select auxiliary behaviour of mouse

27. Collaboration Meeting April 27-29, 2004 Pixel Testbeam Update

28. Collaboration Meeting April 27-29, 2004 Pixel Testbeam Update

29. Collaboration Meeting April 27-29, 2004 Pixel Testbeam Update

30. Collaboration Meeting April 27-29, 2004 Pixel Testbeam Update

31. Collaboration Meeting April 27-29, 2004 Pixel Testbeam Update

32. Collaboration Meeting April 27-29, 2004 Pixel Testbeam Update

33. Collaboration Meeting April 27-29, 2004 Pixel Testbeam Update

34. Collaboration Meeting April 27-29, 2004 Pixel Testbeam Update

35. Collaboration Meeting April 27-29, 2004 Pixel Testbeam Update Conclusion A simple 3D event-display has been developed for the pixel test-beam. (useful to check against obvious mistakes and to help debug the reconstruction code) Wired is currently under development, but for now it provides only limited graphics capabilities (suitable at most for a test-beam) (that’s my opinion…) I do not plan to devote much additional work to this project