AIDA
GELINA
BRIKEN
nToF
CRIB
ISOLDE
CIRCE
nTOFCapture
DESPEC
DTAS
EDI_PSA
179Ta
CARME
StellarModelling
DCF
K40
DESPEC
Draft saved at 00:00:00
Fields marked with
*
are required
Entry time:
Sun Mar 14 08:16:00 2021
Author
*
:
Subject
*
:
> 08:07 Realised the correlation scalers hadn't been enabled again. Have enabled them now. R56_151 > > Looking through the merger messages from the nightshift we see bad timestamps in FEE 11. This FEE does not have any scalers going into it. > It is also the least noisy FEE in the back DSSD > > MERGE Data Link (20510): bad timestamp 10 3 0xc2b77eff 0x037a3b92 0x000017f7f37a3b92 0x166c17f7f37a3b92 0x166c17f7f3877262 > MERGE Data Link (20510): bad timestamp 10 3 0xc2827f3a 0x037aa122 0x000017f7f37aa122 0x166c17f7f37aa122 0x166c17f7f3877262 > > 09:01 System wide checks > > Base Current Difference > aida07 fault 0x8c74 : 0x8c77 : 3 > White Rabbit error counter test result: Passed 11, Failed 1 > > Understand the status reports as follows:- > Status bit 3 : White Rabbit decoder detected an error in the received data > Status bit 2 : Firmware registered WR error, no reload of Timestamp > Status bit 0 : White Rabbit decoder reports uncertain of Timestamp information from WR > > Base Current Difference > aida07 fault 0x2 : 0x5 : 3 > FPGA Timestamp error counter test result: Passed 11, Failed 1 > If any of these counts are reported as in error > The ASIC readout system has detected a timeslip. > That is the timestamp read from the time FIFO is not younger than the last > > Statistics - attachment 1 > Temperature - attachment 2 > Bias and leakage current - attachment 3 It might be worth considering decreasing the time between the flushing of slower FEEs. Is the Merger waiting for the slower data and causing ‘deadtime’ in the faster ones. Perhaps consider this as a balancing across the system?
Encoding
:
HTML
ELCode
plain
Suppress Email notification
Resubmit as new entry
Attachment 1:
Drop attachments here...
Draft saved at 00:00:00
ELOG V3.1.4-unknown