From smarka@ligo.caltech.edu Mon Feb 2 11:15:10 2004 Date: Fri, 30 Jan 2004 15:29:19 -0800 From: Szabolcs Marka To: Keith Riles Cc: zweizig_j@ligo.caltech.edu, Daniel Sigg Subject: Problem segments Hi Keith, We discussed it with Daniel and we think it is the best if we flag the H1/H2 segments where we have seen the timing problem indicated by the IRIG-B signal. With much work quality data can probably be recovered, but it might not be a worthwhile effort. For now we should probably flag these segments. The effected LHO segments are listed within the attached files. Notes: The long H1 segment might have uneffected parts. We might want to consider splitting it and only flag the bad part. The longer H2 segment is totally effected. The shorter H2 segment has some problem, but it might be unrelated to the one investigated by Dave. To be on the safe side we should probably flag it. The LLO IRIG-B timing indicated more and different problems. I will need more time to sort them out. Thanks, Szabi ps: Dave Barker's related e-mail is quoted below. -------- Original Message -------- Subject: Re: fb3 problems;SYNC errors during S3 triple coincidence science mode on Sun Dec 28 2003. Date: Mon, 29 Dec 2003 19:22:54 -0800 From: David Barker Organization: Ligo Hanford Observatory To: Greg Mendell CC: Keith Riles , John Zweizig , Szabi Marka , Dave Barker , Daniel Sigg , Fred Raab , Stan Whitcomb References: <3F1EE8FD.A4048753@ligo-wa.caltech.edu> <3F1F0BD4.F1A9220B@ligo-wa.caltech.edu> <3FF0A3FF.2D9ECC1F@ligo-wa.caltech.edu> I have analyzed the DAQ data for this time period, here is what I found. On Sunday, 28th Dec. from 12:34:27 UTC to 18:53:00 UTC (gps 756650080 to 756672784) the DAQ controller was in SYNC fault state. The vxworks shell stdout was reporting a time difference of 2 seconds between the daq controller internal clock and the GPS time. For historical reasons, when there is a time discrepancy then the internal time is used (there was a time when the GPS was glitchy). When this SYNC error has happened before, we have always immediately reset the DAQ system. It was not done at this time because we were in a triple coincidence state. I looked at the fast RAMP signals and verified the frames during the SYNC event were aligned to the start of the GPS second (no time slips within the current second). I then decoded the fast IRIG-B signals, which are the only independent GPS times contained within the frame data. (I will add the slow GPS channels after S3). We have three IRIG-B signals, all H1, from EX, EY and 4k LVEA. During the sync event, all data which passed through the DAQ controller are delayed by one second. This applies to all framed data except those which are acquired by the LVEA ADCU units. These ADCUs are directly connected to the frame builders and do not pass through the daq controller, and therefore were not affected by the controller sync error. How can I document this information for the analysis teams? I can put together a list of channels which do not have a time slip ( the lesser list of the 8000 channels in the frame). Did we make the correct decision to continue running the DAQ with time errors, or should we have rebooted the DAQ at the time of the fault (or when LLO went out of science mode)? Dave. -- Dave Barker, LIGO Project, Software Engineer US-Mail: PO Box 159, Richland WA 99352 Shipping: Mile Marker 2, Route 10, Richland WA 99352 Phone (509) 372 8103 Fax (509) 372 8137 email barker@ligo-wa.caltech.edu [ Part 2: "Attached Text" ] Seg# Start Stop Dur Min[ms] Max[ms] Ave[ms] Sig[ms] 310 755028455 755029446 991 2538.46 -100.00 137.56 619.25 578 756651376 756672757 21381 -1000.00 -1000.00 -1000.00 0.00 [ Part 3: "Attached Text" ] Seg# Start Stop Dur Min[ms] Max[ms] Ave[ms] Sig[ms] 435 756605166 756672768 67602 0.00 -1000.00 -336.00 472.34