|
|
| (2 intermediate revisions by one other user not shown) |
| Line 1: |
Line 1: |
| − | 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).
| |
| − |
| |
| − | ==== 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.
| |
| − |
| |
| − | === 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.
| |
