Difference: PilotBladeReconstructionLogs (10 vs. 11)
Revision 112016-11-22 - TamasVami
| Line: 1 to 1 | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
| Line: 8 to 8 | ||||||||
Link to the git repository
| ||||||||
| Added: | ||||||||
| > > |
Log entry on 2016-11-22From Karl: http://cmsonline.cern.ch/cms-elog/960640 Indeed this is troubling. Looking into log files[1] from the run where the timing scan happened, I see pixel FEC programming errors reported during the pause/reconfigure/resume steps. For the fine timing scan we actually are not changing WBC (on the ROCS), but the pause/resume steps do reprogram the ROC DACs in order to disable ROCs and raise thresholds during PAUSE and re-enable during RESUME. A possible explanation for the bad behavior we see is that for some ROCs the re-enable and/or threshold change did not happen as intended due to a transmission error. Either of these should affect the entire ROC. From the DQM hit map, it looked like this is consistent. Many more of these errors happen for BmI than BmO . We've attributed this to marginal signal quality on the FEC fibers to the pilot blades. Similar things happened during WBC scans. A suggestion is to consider repeating the scan and watching the PixelFECSupervisor log file for errors. We may be able to Pause/Resume again to get good programming. We could also try to bypass the disable during the timing scan. It would then give three attempts to get it correct (Pause, Reconfigure, Resume) rather than one. Once uTCA FECs are ready for running (next week?) we will want to repeat the timing scan. We could possibly do it sooner with VME. | |||||||
Log entry on 2016-11-14htemp->GetXaxis()->SetRangeUser(-1.7,1.7); | ||||||||
View topic | History: r14 < r13 < r12 < r11 | More topic actions...
Copyright &© by the contributing authors. All material on this collaboration platform is the property of the contributing authors. Ideas, requests, problems regarding TWiki? Send feedback