Rate set and rate measured

Misura rate rumore durante i normali run di acquisizione

Dalla versione 3.2 di GUFI GUFI updates#GUFI V.3.2 è possibile equalizzare le soglie al valore di rate desiderato.

Sono stati acquisiti 3 run con un rate impostato differente: RUN 333 a 5 kHz, RUN 334 a 17 kHz e RUN 335 a 33 kHz.

Analizzando i run acquisiti si può fare una misura del rate di rumore andando a contare il numero di eventi fuori dalla finestra temporale di segnale.

Dalle misure sui dati si nota che il run misurato è inferiore a quello impostato, tranne in alcuni casi in cui il rate arriva a valori significativamente più elevati.

I valori misurati sono: RUN 333 a 3.0 kHz, 334 a 7.8 kHz e 335 a 11.0 kHz.

Misura del rate con TP digitali

Sono stati fatti diversi run in cui il trigger veniva generato con un rate fisso a 100 Hz e sui TIGER veniva generato per ogni FRAMEWORD un o più segnali di TP per ogni chip.

Il risultato di questa misura è stato inconcludente poiché il valore di rate misurato risultava essere maggiore di quello generato, contrariamente quando visto sopra.

Da uno studio dei pacchetti si è visto una grossa componente di dati spuri.

Guardando la distribuzione dei tempi dei TP generati si nota un picco nella distribuzione temporale che contiene un numero di TP compatibile con quelli generati.

Link alla presentazione: File:Sul rate.pdf

Too high rate from digital TP ("extra" test-pulses)

Tcoarse distribution of TP signals

During the tests for the measurement of the Trigger-Matched rate we sent digital TPs to channel 62 of all TIGERs. The number of TP was set to one per frameword (i.e. 2 TP per Tcoarse cycle, 2^16 TIGER clocks), all other channels were disabled (trigger_mode=3). Only test-pulses detected by all 8 TIGERs of a GEMROC were considered in order to avoid spurious data generated when the data rate sent from the TIGERS to the GEMROC is very low as in this case.

Plotting the Tcoarse distribution we observe 2 peaks corresponding to the 2 TPs per Tcoarse cycle (they are perfectly separated by 2^15 clock counts, as expected) plus other small peaks. If we take only the entries from the 2 peaks the measured rate is compatible with the expected one (5 kHz). But if we consider all registered TPs, also the ones from the other peaks, this provides a measured rate higher than expected.

Possible explanations (to be investigated)

• In addition to the TPs generated by the GEMROC at each frameword, we also detected the TPs generated at each check signal: the GEMROC can be configured to send a TP to the TIGER each time a check signal arrives. It is very likely that during these tests this feature was enable and thus we were generating TPs also for each cosmic detected by the scintillator bars coincidence (i.e. the usual trigger signal).
• Moreover, the check signal seems to be generating some interference in the system