ELOG AIDA

AIDA GELINA BRIKEN nToF CRIB ISOLDE CIRCE nTOFCapture DESPEC DTAS EDI_PSA 179Ta CARME StellarModelling DCF K40

AIDA

Fields marked with * are required
Entry time:	Sat Mar 29 07:29:22 2025
Author*:
Subject*:
> > A first look at the data from the 207Bi source (run described in previous elog entry, ID 27) > > The main conclusions are (see description of spectra further bellow): > > - NNAIDA11 and NNAIDA13 were running stable, even though NNAIDA11 had one channel with very high rate. > NNAIDA12 and 14 were running unstably with frequent instances of Pause/Resume. A possible explanation is > their higher data rates (due to a bad channel and noise, respectively). > > - I think using only a window in time will not be sufficient to identify electron signals in the data. > This is a particular issue for the data of NNAIDA14, where there is a high noise and a energy threshold, > or some more ingenious condition, is likely required. > > > Plots were generated with the script in /Home/aestrade/AIDA/analysis/loopAIDAsort.cpp > > Only a fraction of the 207Bi data was processed (corresponding to file R62_2). > > > + Distribution of time-stamps > > R61part_ts_dist_adc_hit.png: The spectra show the difference between the > time-stamp of a given ADC hit (ts_i) and the time-stamp of subsequent ADC > hits (ts_i+n): > > Delta ts(i+n,i) = ts_(i+n) - ts(i) > > So the first plot, for Delta ts(i+1,i), is the difference between each ADC > hit and the next ADC hit. The second plot is the ts difference between each > ADC hit and the second to next ADC hit, and so on... > > The data mixes the spectra for all FEE cards and all ADC channels. One can > still see a clear structure with a peak at low values of Delta ts, and then > a second distribution up to Delta ts= 30n usec. These is the time it takes > to loop through all 16 channels of the ADC (2 usec/channel), so is likely > the distribution generated by one channel is firing at a very high rate. > > I'll make similar plots with conditions to mask out noisy channels and/or > pulser events to look for a value of the coincidence time-window to use to > reconstruct events. > > + Rates > > R61part_rates.png: the spectra shows various rates (in Hz) as a function of > run time and of channel. The plots on the top are the rate of ADC hits (for > low energy range) of each FEE module, and one showing the rate of ADC hits > for the high energy range in all modules combined. The bottom row shows rate > per channel, and the rate of Information type hits. > > some conclusions: NNAIDA11 and 13 show a flat rate, and as will be seen from other plots are very stable > during the run. NNAIDA11 has a larger rate than 13, but the difference is mostly due to a very high-rate > channel; the rate in most channels is consistent with a 100 Hz pulser for both. > > NNAIDA12 and 14 show the largest rate that can peak at 35kHz, and looks quite unstable. These modules also > have a choppy run of the DAQ (many Pause/Resume). NNAIDA11 actually has similar rate to NNAIDA12 and 14, > but is still stable. > > Both NNAIDA11 and 12 have one channel wiht very high rate compared to the > rest (rather than unusually noisy channel, could it be one that is always > above the threshold of the slow discriminator?). > > > + ADC Rate with fine granularity > > R61part_t1_hits_ts_adc.png: These spectra show the ADC hits (low range) vs time but with a higher binning > of the data (1 ms/bin). The one channel with a very high rate in NNAIDA11 and 12 is seen in red. Also that > the data readout from NNAIDA12 and 14 is frequently halted by Pause/Resume signals. > > R61part_t1_hits_ts_adc_zoom.png: The second file hast the same spectra but zoomed in a narrow time window, > and one can see the hits from the pulser 10 ms appart (as vertial lines with hits in all channels for 2D > spectra). In between the pulser signals, as hits in individual channels, are hits from the source or from > noise. For NNAIDA14 this white noise was very high, so at the binning of 1ms/bin this spectra there are > many channels with hits in each time bin. I think it will be difficult to identify electron events from > such spectra using only a time window as requirement for coincidence. > > > + Info Codes Rates > > R61part_t1_hits_ts_info.png : The spectra show the rates of information words. The first plots are again > for a narrow section of the run (same as previous spectra). One can see the frequent sequence of > Pause/Resume for NNAIDA12 and 14. Also note discriminator data and ADC(high range) hits only come for > NNAIDA12 (we used very high value for discriminator threshold). > > R61part_ts_info_fee.png: The figure shows the distribution of the different information codes for each FEE > module, but now for the full lenght of the run. > > > > ++ Sorted Root TTree fiels ++ > > All raw files of run R61 were processed with the 'beta' version of the Root > sort code for event reconstruction (/homes/npg/AIDAsort/ in DL PC), but only > up to the 'Calibration' step (no event reconstructino). > R61_207Bi_2_sort.root used for above plots. > > Root tree saved here: > > /Disk/ds-sopa-personal/aestrade/rootfiles/AIDA/R61_207Bi_0_calib.root > /Disk/ds-sopa-personal/aestrade/rootfiles/AIDA/R61_207Bi_0_sort.root > /Disk/ds-sopa-personal/aestrade/rootfiles/AIDA/R61_207Bi_1_calib.root > /Disk/ds-sopa-personal/aestrade/rootfiles/AIDA/R61_207Bi_1_sort.root > /Disk/ds-sopa-personal/aestrade/rootfiles/AIDA/R61_207Bi_2_calib.root > /Disk/ds-sopa-personal/aestrade/rootfiles/AIDA/R61_207Bi_2_sort.root > /Disk/ds-sopa-personal/aestrade/rootfiles/AIDA/R61_207Bi_3_calib.root > /Disk/ds-sopa-personal/aestrade/rootfiles/AIDA/R61_207Bi_3_sort.root > /Disk/ds-sopa-personal/aestrade/rootfiles/AIDA/R61_207Bi_4_calib.root > /Disk/ds-sopa-personal/aestrade/rootfiles/AIDA/R61_207Bi_4_sort.root > /Disk/ds-sopa-personal/aestrade/rootfiles/AIDA/R61_207Bi_5_calib.root > /Disk/ds-sopa-personal/aestrade/rootfiles/AIDA/R61_207Bi_5_sort.root > > > A bug on the Root sort code was identified from this output: the code waits > for a SYNC100 pulse from each* FEE card to update their corresponding > most-significant bits (MSB) for the timestamp, while one has to use any > SYNC100 pulse to update the MSB of all FEE modules. As a consecuence, a > (very small) fraction of the processed hits have the wrong time-stamp (off > by bit 28). Encoding: HTML ELCode plain Suppress Email notification

Attachment 1:
Drop attachments here...

ELOG V3.1.4-unknown