Result June Integration Week

Here we are going to post some of the results achieved during the weeks to keep track of the developments.

Preliminary tests in synchronization

We run some tests on the synchronization and the situation seems promising, because the chip synchronizations seems OK and the other problems seem localized and understandable.

First of all we run a new acquisition with digital test pulses injected after cosmic triggers. The results are:

• The signals from the TIGER have the same time signature (Tcoarse) for each trigger.
• If a GEMROC has trouble with the clock distribution, it will not be in synchronous with the others (but its TIGERs are still in sync among each other)
• There can be some spurious trigger on the line (probably due to reflections). This causes the number of L1 counts to be not aligned anymore. We can look at the trigger arrival time "LOCAL L1 TIMESTAMP" to correctly put together the hits.

Moreover, we take a look at the run 58 inspecting the decoded file and notice that:

• All the TIGERs seems in synchronous in both L1 and L2
• The only sync problem was in GEMROC 6, which counted, in 5 seconds , 4 clock cycles more than the others (we already know from the 8b/10b errors on all its TIGERs that GEMROC 6 has some clock problem).
• Other anomalies come from the fact that the trigger period ranged during the acquisition from 380uS to 0us (less than we can measure) and then rising back up to ~10us. This is due to the meta-stability of the double timer used like pulse generator. When the triggers were very fast, multiple test pulses were generated in the same trigger window and sometimes the same events were correctly taken 2 times (because 2 very near trigger insisted on the same trigger window).

A confirmation of these results has been performed with the reconstructed run 125, 134 and 139:

• The synchronization within 1 clock is better than 95%
• The communication between 12 chip and the GEMROC is not properly working: 2 chip have known problem, the other 10 are under investigation

Summarizing

Good things:

• The chips synchronization seems very good
• The GEMROC seems capable to build packets at a very high trigger rate and to recover it's normal work flow even after an intense trigger burst

Bad things and proposed solutions

• We have some issue with the clock distribution (solution: the fan-out board that Angelo is finishing)
• We have some issue in trigger and check distribution (same as above)
• Double timer is not a reliable source of signals (the fan-out board will be able to generate them)

Bump in Time distribution

From the analysis of run 101-102 and run 107-108 it seems that the bump has disappeared. Need to check the configuration file to identify possible misconfiguration in the runs that may have caused/canceled the bump in the noise time distribution. It seems that the time peaking background is present in random trigger run only when the rate is bigger than 100 Hz. At 500 Hz the peak is present.

Mapping

A full review of the mapping of both L1 and L2 has been applied based on the indication from data taking.

Based on the anode connection, strip V on L1 and L2 were reversed on one side of the detector. Mapping of the strip X on L2 was reversed left-right.

Data analysis

The charge distribution of the hits is not under control: incongruence between run 134 and 139 are under investigation

Charge and time distributions are reasonable and it looks that we are extracting the proper signal from the events

Cluster size and cluster charge, if the threshold are low enough, are in agreement with the TB measurement with APV and TIGER

Effects of HV, induction field and threshold cut is understood and it is reasonable