FA125 firmware check
Used the raw samples to emulated the fa125's calculated values and compared them with the fa125 output.
Looked at the first evio files from runs 3293 (2 weeks old) and 4062 (this week).
| Run | total events | complete events | time | q | amplitude | pedestal | integral | overflow count |
| 3923 | 16582555 | 1160 | 1942 | 3547 | 15609 | 1 | ||
| 3923 minus 2 bad fadcs | 15914850 | 378 | 1877 | 288 | 12798 | 1 | ||
| 4062 file 000 | 10249118 | 0 | 98 | 0 | 3 | 0 | ||
| 4062 file 000 | 10249118 | 0 | 98 | 0 | 3 | 0
|
Many of the problems in 3923 were due to hardware faults in roc28 slots 5&6.
11770 of the 12798 difference in integral were due to faulty assignment of the overflow bit. This has been fixed.
There were a few problems in the firmware which Cody described & fixed before run 4062. The remaining issues are not critical.
Differences in data/emulation from run 4062
The first 4 are firmware logic, & not necessarily a mistake (could be a mistake in the emulator); the remaining 3 are more weird.
1. Integral differences - these are from very late hits where there is a small peak at the end of the hit search window that only just clears the threshold crossing, followed by a larger peak a few samples later. The timing algorithm returns the time for the larger peak and the emulated integral is 0 because it is out of the window.
2. Amplitude differences - both firmware and emulation are starting the peak search from the threshold crossing sample but it should really start from the sample containing the leading edge time, since very occasionally the search will pick up a different peak (usually a small one before a larger one).
3. Amplitude differences - early hits - 70 of the 98 differences are where the samples at the start of the window are over threshold, decrease for one sample and then rise again, ie. hitsample==20 && (adc[20]>=adc[21]) && (adc[21]<adc[22]) where adc[20] is the first sample in the hit search window. Emulator returns maxamp = adc[20]; firmware returns amp of the following peak.
4. Amplitude differences - later hits - 28 of the 98 differences seem to have no apparent cause, no association with roc/slot/channel, in most cases the max amp reported is larger than all the sample values
5. Missing pulse or WRD - pulse & Window raw data are separate objects in the evio eventloop, not linked yet. One out of sync pair causes the rest of the data for that trigger to be out of step.
Run 3923 had 7600 entries with pulse and WRD out of step due to 252 hiccups.
Run 4062 had 1317 entries with pulse and WRD out of step due to 33 hiccups.
Not enough samples
- infrequently (0 to 10 times per 10 million events??) the window raw data contains less than the prescribed number of samples. This is hard to quantify because hd_root used to crash the first time it was encountered. David fixed this, and it now crashes less often. So far I can say that in the first file for run 3923 there were no occurrences whatsoever, in the second file there were 148 occurrences, and in the next 3 files there were none.Update: with an updated and recompiled sim-recon, hd_rawdata_003923_002.evio was processed without crashing.
fa125 object mismatches
ie when the nth digihit contains a CDCPulseData object for a hit channel differing from that for the nth windowrawdata object. Usually they match. Every now and then a CDCPulseData is missing from the start of an event and then the following subsequent objects are out of step for a while (the mismatches continue into following events and eventually stop). Sometimes there is a lone WRD object first and a lone CDCPulseData at the end, but sometimes the lone objects are not found and only the mismatched pairs are found.
Run 4062 Naomi sees mismatches using a hd_root plugin but Beni does not, using his independent analyzer.
Run 4127 all the CDC pulse hits are paired with FDC window data.
