Displaying reports 62081-62100 of 85001.Go to page Start 3101 3102 3103 3104 3105 3106 3107 3108 3109 End
Reports until 20:56, Wednesday 18 November 2015
H1 AOS
edmond.merilh@LIGO.ORG - posted 20:56, Wednesday 18 November 2015 (23541)
H1 Observation Intent Bit Set to Observe!

04:56UTC

H1 General
edmond.merilh@LIGO.ORG - posted 20:18, Wednesday 18 November 2015 (23540)
Mid-Shift Summary - Evening

MID-SHIFT SUMMARY: Locking is a bit of an arduous task. There has been beam pointing issues, alignment of DRMI issues (not that uncommon), IR resonance issues and Cage Servo issues. Now it seems as though OMC has us stopped on ENGAGE_ASC_PART3. Winds are calm. Seismic environment is ok.

 

H1 IOO (OpsInfo)
cheryl.vorvick@LIGO.ORG - posted 17:08, Wednesday 18 November 2015 - last comment - 21:10, Wednesday 18 November 2015(23538)
alignment changes since 11/13

Plot shows two bigh alingment changes:

1) 13 Nov 2015 start at 17:00UTC, first jump 22:00UTC, IM2 Pitch changes 46urad, IM3 pitch jumps 5urad and continues to drift another 5urad.

2) 14 Nov 2015 at 23:00, IM1 Yaw jumps 15urad, and IM4 pitch sees a jump of 50urad - this might be an alignment change.

The first jump in alignment can clearly be seen in channel 9, IM4 Trans Pitch, and ISS Second Loop QPD Yaw.

The second jump in alignment can clearly be seen in channel 2, IM4 Trans yaw, and ISS second loop pitch.

Currently, Kiwamu is adjusting the alignment.

Images attached to this report
Comments related to this report
kiwamu.izumi@LIGO.ORG - 21:10, Wednesday 18 November 2015 (23542)ISC

Patrick, Ed, Kiwamu,

We had a trouble locking the full interferometer today. The difficulty seems to have gone away after realigning the input pointing (i.e. IMs and MCs suspensions).

The symptom we saw was that the PRC2 PIT loop for some reason ran away in the full lock ENGAGE_ASC sequences. This resulted in a rapid degradation (on a time scale of 10 sec or so) in the power recycling gain followed by lockloss. We experienced this problem three times in a row from the beginning. By they way, we did not experience such an issue yesterday because we did not attempt to fully lock due the combination of the maintenance and high wind.

I suspected the following two things

  • (1) input pointing (see Cheryl's alog above) somehow messing up the ASC sensing matrix,
  • (2) the change in the modulation depth for the 45 MHz (alog 23472) impacting on the ASC sensing matrix.
    • The modulation depth should be now 7 or 8% lower than it used to be. This may be critical since we derive the PRC2 error signal by linearly combining REFL9 and REFL45.

While both sounded suspicious to me, we started to address the input pointing as a first step. Since the problem seems to be gone after the realignment, we did not attempt to investigate the blending ratio between REFL9 and REFL45.

 

Re-alignment of the input optics

The philosophy is the same as previous processes (for example, alog 22871). Regardless of what moved the IM and MC suspensions, we move them back to the place where the OSEMs read the same value as they had been before. Specifically, I have touched MC3 YAW, IM1 YAW, IM2 PIT, IM3 PIT. However moving them back did not recover the YAW pointing on IM4_TRAS which I do not know why. On the other hand, the PIT spot position on IM4_TRANS came back to where it should be (~ 0.4 counts). I decided to move IM3 YAW to recover the pointing on IM4_TRANS (~0.05 counts nominally). I could have touched IM2 YAW instead, but I was afraied of screwing up the REFL beam and hence IM3.

After the realignment, we went through the initial alignment. The PRC2 loop seems stable so far.

LHO General
patrick.thomas@LIGO.ORG - posted 16:49, Wednesday 18 November 2015 (23537)
Ops Day End Shift Summary
TITLE: 11/18 [DAY Shift]: 15:00-23:00 UTC (08:00-16:00 PDT), all times posted in UTC
STATE Of H1: Lock acquisition
SHIFT SUMMARY: Initial problems with ESD driver. Ran initial alignment. Offloaded dark offsets for ASAIR_B_RF90. Large earthquake in Solomon Islands. HAM5 ISI, ITMX ISI and SUS SRM watchdogs tripped. Cleared IMC WFS histories to relock IMC. Betsy ran charging measurements while waiting for earthquake to ring down. Guardian glitch. Ran initial alignment. Lost lock after reaching ENGAGE_ASC_PART3 and then after reaching ENGAGE_ASC_PART2. Will stop at ENGAGE_ASC_PART1 to allow Kiwamu to check of ASC loops.
INCOMING OPERATOR: Ed
ACTIVITY LOG:

16:06 Jeff B. to mechanical building to check on TCS chillers
16:12 Jeff B. back from mechanical building
16:57 Jeff B. back from getting garb
17:01 Filiberto and Gerardo back from resetting ESD at end Y
17:01 Filiberto plugging control room GPS clock into IRIGB chassis
17:15 Karen and Christina clearing tumbleweeds off stairs to roof
17:19 Richard and Filiberto to roof to check on dangling cables
17:22 Chris to work on beam tube enclosure 5 doors from end X
17:33 Karen and Christina done clearing tumbleweeds off stairs to roof
17:44 Joe D. to work on X arm beam tube enclosure
Landscapers are bailing tumbleweeds
17:47 TJ reloading diag main to add check for PMC HV
19:06 Travis to LVEA to look for part
19:14 Travis back from LVEA
19:49 Gerardo forklifting diesel container out of bunker
20:09 Joe D. back
20:38 Gerardo done with forklift
20:58 Betsy running charge measurements
21:49 Richard to DC power mezzanine to look at PEM radio
22:01 Betsy done running charging measurements
22:04 Richard tuned PEM radio antenna frequency
22:12 Gerardo using forklift to unload diesel tank at bunker
22:17 Kyle driving down X arm to assess tumbleweed bailing progress
22:29 Gerardo done
22:44 Kyle back
H1 General
edmond.merilh@LIGO.ORG - posted 16:02, Wednesday 18 November 2015 (23534)
Shift Summary - Evening Transition

TITLE: Nov 18 EVE Shift 00:00-08:00UTC (08:00-04:00 PDT), all times posted in UTC

STATE Of H1: Locking

OUTGOING OPERATOR: Patrick

QUICK SUMMARY: @ the Lock DRMI 1F stage. µSeis is trending down towards the .5µm/s mark and eq bands have settled back down to .02µm/s territory. Winds are calm again.

 

H1 General
patrick.thomas@LIGO.ORG - posted 15:47, Wednesday 18 November 2015 (23533)
Done initial alignment, attempting to lock


			
			
H1 GRD (GRD, ISC, OpsInfo)
cheryl.vorvick@LIGO.ORG - posted 15:46, Wednesday 18 November 2015 - last comment - 21:47, Wednesday 18 November 2015(23532)
Initial alignment X arm red locking gain increased

I edited lscparams.py to set the initial alignment X arm IR gain higher, to match the gains we're having to enter manually to get the arm to lock in red.

Included below are the line I changed, and the previous comments.

arm_IR_gain['X'] = 0.15 # was 0.05 and doesn't lock, bumped up to 0.15, CV 18 Nov 2015
#was 0.08 until August 18 2015 # was 0.12 as of Apr-16-2015 and bit too high
#arm_IR_gain['X'] = 0.2 #should be 0.2 to acquire lock
 

Comments related to this report
kiwamu.izumi@LIGO.ORG - 21:47, Wednesday 18 November 2015 (23544)ISC

Later today, we set the gain back to the nominal of 0.05 since it was too high and the servo ran in to a loop instability. See alog 23543.

H1 General
betsy.weaver@LIGO.ORG - posted 15:02, Wednesday 18 November 2015 (23531)
ETMs opticalignment steered off course yesterday during charge measurement

Upon relocking this morning, after a long night of super-winds, Keita and Patrick immediately found that the ETMs were way off in alignment.  We sleuthed around in the trends and can re-tell some of the confusion from yesterday's lunch time:

After Keita/Kiwamu took a break from phase measurments using a Michaelson lock, I used the lunch hour to take charge measurements.  Although set to ALIGN at the start of the measurements, during them, I noticed that something was telling the ETMs to go to the MISALIGN state, even though all top guardians were set to DOWN.  We ended up PAUSING some of them and then did not witness any problems afterwards.  From trends we can now see that the during the full set of measurements (automated 5 sets during ~1hour) the charge script used the OPTICALIGN sliders to return the optic pointing to zero on the oplev while the optic was MISALIGNed via the normal TEST OFFSETs.  A measurement later, we had reset the guardian to ALIGN and so the script drove the OPTICALIGN sliders back to nominal (again returning to zero on the oplev).  However, because the optic had so far to move, it bounced for a bit and the script "timed out", resetting the OPTICALIGN to it's script-restored bad pointing values.  These values were written into subsequent restore files by the script and therefore the optic never returned to the nominal pointing once the script concluded like it should.

Long story short - while there are a few places in the charge script which look for the guardian state to be correct, it may not always get returned, so watch it.  In the above case, we could increase the amount of "tries" it uses for the optic to quit swinging while zeroing on the oplev (which is short when in-between measurements).

Images attached to this report
H1 General
patrick.thomas@LIGO.ORG - posted 14:15, Wednesday 18 November 2015 - last comment - 14:46, Wednesday 18 November 2015(23525)
Relocking
Earthquake band has settled down. Attempting to relock.
Comments related to this report
patrick.thomas@LIGO.ORG - 14:20, Wednesday 18 November 2015 (23527)
Modes at locking DRMI look bad. Attempting to lock PRMI.
patrick.thomas@LIGO.ORG - 14:32, Wednesday 18 November 2015 (23528)
Locked PRMI and aligned BS/PRM. Aligning PRM seemed to be the only thing that helped. Attempting to lock DRMI.
patrick.thomas@LIGO.ORG - 14:46, Wednesday 18 November 2015 (23530)
Starting initial alignment again. Spot on AS AIR port looks high and is not flashing well.
H1 CDS (GRD)
patrick.thomas@LIGO.ORG - posted 14:05, Wednesday 18 November 2015 - last comment - 14:44, Wednesday 18 November 2015(23524)
Guardian restart?
Got a virtual circuit disconnect for guardian and the ISC_LOCK node request is at NONE.
Comments related to this report
patrick.thomas@LIGO.ORG - 14:44, Wednesday 18 November 2015 (23529)
2015-11-18T21:57:44.47380 ISC_LOCK stopping daemon...
2015-11-18T21:57:44.59302 ISC_LOCK daemon stopped.
2015-11-18T21:58:11.57521 Traceback (most recent call last):
2015-11-18T21:58:11.57525   File "/usr/lib/python2.7/runpy.py", line 162, in _run_module_as_main
2015-11-18T21:58:11.58327     "__main__", fname, loader, pkg_name)
2015-11-18T21:58:11.58330   File "/usr/lib/python2.7/runpy.py", line 72, in _run_code
2015-11-18T21:58:11.58332     exec code in run_globals
2015-11-18T21:58:11.58334   File "/ligo/apps/linux-x86_64/guardian-1485/lib/python2.7/site-packages/guardian/__main__.py", line 262, in 
2015-11-18T21:58:11.59775     guard.run()
2015-11-18T21:58:11.59783   File "/ligo/apps/linux-x86_64/guardian-1485/lib/python2.7/site-packages/guardian/daemon.py", line 457, in run
2015-11-18T21:58:11.60796     raise GuardDaemonError("worker exited unexpectedly, exit code: %d" % self.worker.exitcode)
2015-11-18T21:58:11.60806 guardian.daemon.GuardDaemonError: worker exited unexpectedly, exit code: 1
2015-11-18T21:58:12.16625 guardian process stopped: 255 0
2015-11-18T21:58:18.52504 ISC_LOCK Guardian v1485
2015-11-18T21:58:18.52516 ISC_LOCK EZCA v497
H1 AOS (DetChar, INJ)
christopher.biwer@LIGO.ORG - posted 13:18, Wednesday 18 November 2015 (23520)
new set of BBH waveforms for testing with PCAL
I've tested a new set of 10 CBC waveforms for testing with the PCAL inverse acutation filter.

The waveform parameter XML files can be found here: https://daqsvn.ligo-la.caltech.edu/svn/injection/hwinj/Details/Inspiral/coherentbbh${NUM}_1128678894.xml

Where ${NUM} is between 10 and 19.

The single-column ASCII files can be found here: https://daqsvn.ligo-la.caltech.edu/svn/injection/hwinj/Details/Inspiral/${IFO}/coherentbbh${NUM}_1128678894_${IFO}.out

Where ${IFO} is either H1 or L1.

I've attached time series of the counts after being filtered with the PINJX inverse actuation filter. The maximum number of counts in the set of 10 waveforms is 4000 counts.
Images attached to this report
H1 General
betsy.weaver@LIGO.ORG - posted 12:59, Wednesday 18 November 2015 (23521)
Using EQ time for charge measurements

Just started them on ETMx and ETMy.  We'll see what they look like...

H1 General
patrick.thomas@LIGO.ORG - posted 11:24, Wednesday 18 November 2015 - last comment - 14:17, Wednesday 18 November 2015(23513)
Watchdog trips
ISI ITMX, HAM5
SUS SRM

Eathquake band seismic now above 10 um/s.

See attached.
Images attached to this report
Comments related to this report
patrick.thomas@LIGO.ORG - 12:22, Wednesday 18 November 2015 (23515)


		
		
Images attached to this comment
patrick.thomas@LIGO.ORG - 12:25, Wednesday 18 November 2015 (23516)
Reset
patrick.thomas@LIGO.ORG - 12:28, Wednesday 18 November 2015 (23517)
HAM5 and ITMX ISI retripped almost immediately.
Images attached to this comment
patrick.thomas@LIGO.ORG - 12:36, Wednesday 18 November 2015 (23518)
Put GS13s into low gain and reset again. So far so good.
patrick.thomas@LIGO.ORG - 14:17, Wednesday 18 November 2015 (23526)
Set both back to HIGH gain,
H1 General
patrick.thomas@LIGO.ORG - posted 10:57, Wednesday 18 November 2015 - last comment - 12:50, Wednesday 18 November 2015(23511)
Earthquake
6.8
119km SW of Dadali, Solomon Islands
2015-11-18 18:31:04 UTC 10.8 km deep

Spike above 1 um/s in both earthquake and microseism bands.
Comments related to this report
patrick.thomas@LIGO.ORG - 12:50, Wednesday 18 November 2015 (23519)
USGS updated it

7.0
122km SW of Dadali, Solomon Islands
2015-11-18 18:31:04 UTC 10.9 km deep
H1 ISC
keita.kawabe@LIGO.ORG - posted 21:55, Tuesday 17 November 2015 - last comment - 17:47, Wednesday 18 November 2015(23472)
RF45 AM work (Kiwamu, Keita)

What was done:

  1. RF AM measurement unit (D0900891) installation.
  2. Taping down 45MHz cable from the ISC ract to the EOM driver.
  3. Rephasing

1. RF AM measurement (D0900891) unit installation

To better diagnose the problem, we inserted RF AM measurement unit (D0900891) between the EOM driver and the EOM.

For connection cartoon, see the first attachment.

The unit was placed on top of the DCPD interface box that was next to the EOM driver.




Couplers are connected back to back such that the first one sees the forward going RF, the second one the reflection from EOM. Insertion loss of one coupler is rated 0.3dB and this was confirmed by the power measurement. Driver output was 23.34dBm (measured by RF meter with 30dBm attenuator), after the second coupler it was 22.67, so the insertion loss of two couplers is 0.67dB. We didn't do anything to compensate, it's not a big deal. But this means that the modulation index is smaller by that much.  

EOM reflection was measured by looking at reverse direction coupler output on the scope, which was about -11.6dBm (about 59.1 mVrms with 50 Ohm input). The reflection from EOM should be something like 20-11.6=9.4dBm, i.e. EOM is only consuming 22.67-9.4 ~ 13.3dBm.

Just so we can, Kiwamu tightened the SMA connectors on the EOM inductor box. We also wiggled various things but didn't get any new insight except that wiggling/tapping power cable/connector on the EOM driver and on +-24V distribution strip didn't do much.

Forward going coupled output was connected to the manually adjusted channel. Front panel was adjusted so the MON voltage becomes closest to zero. That was MON=-300mV at  2.6dBm setting.

Reverse going couple output was connected to the automatically biased channel.

This unit needs >+-28V supply in addition to +-17. Filiberto made a special cable that has bananas for +-30V and usual 3-pin for +-17, and we put a Tenma supply outside of the PSL room for +-30V-ish.

A long DB9 was routed from CER to the PSL rack, and a short one was routed from the PSL rack to the RF AM measurement unit, for DAQ. This was plugged into the spigot that was used for the spare EOM driver unit before (i.e. "RF9" monitors).

H1:LSC-MOD_RF9_AM_ERR_OUT_DQ and H1:LSC-MOD_RF9_AM_CTRL_OUT_DQ are for EOM reflection monitor.

H1:LSC-MOD_RF9_AM_AC_OUT_DQ and H1:LSC-MOD_RF9_AM_DC_OUT_DQ are the channels for forward going RF monitor. AC corresponds to ERR and DC to CTRL.


2. Taping down 45MHz cable

We changed the routing of the RF cable between the driver and the ISC rack. Inside the PSL room, it used to go under the table but over the under-table cable tray, and kind of floating in the air from the floor to the cable tray, and from the cable tray to the EOM driver, pushed by other cables.

We rerouted the cable so that it never leaves the floor, and taped it to the floor using white tape. We also taped down some of the cables that were pressing against the RF cable. See the second attachment.


3. Rephasing

In the lab, the delay of the double couplers alone for 45.5MHz signal was measured to be about 0.8 ns or 13 degrees. Kiwamu made a long cable, we added two N-elbows, and we measured the transfer function from ASAIR_A_RF45_I_ERR to Q_ERR. We ended up having:

Q/I = +4.45 (+-0.14), or 77.3 (+-0.4) degrees.

Before the installation this was 77.5 (+-0.1) deg (https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=23254), so this is pretty good.

Images attached to this report
Comments related to this report
keita.kawabe@LIGO.ORG - 17:47, Wednesday 18 November 2015 (23539)

One day later, two things.

1. RFAM monitor unit glitch more often than the RF45 stabilization.

The dataviewer plot starts just before we were done with the installation/phasing, there is a huge glitch which was caused by us, and after that RF45 channels were relatively quiet. Four vertical lines in the dataviewer plot show the time of different dtt traces. In the DTT plot, bottom is forward-going RF monitor and the top is reflection.

It's hard to believe that this is real.

One thing is that the Tenma +-30V ground was connected to the ground of the AC outlet on the outside wall of the PSL room and the +-17V ground of the ISC rack at the same time.

Tenma mid point of +-30V - Tenma GND on the front panel - AC outlet ground
|
ISC rack GND (via +-17V cable)

We might (or might not) be better off disconnecting the +-30V mid point from Tenma GND on the front panel, so I did that at around 11-19-2015 1:39 UTC. Current draw of Tenma supply didn't change by this.

After the change:

Tenma mid point of +-30V (floating from Tenma GND on the front panel - AC outlet ground)
|
ISC rack GND (via +-17V cable)

I don't know if the +-17V ground on the ISC rack is the same as +-24V ground inside the PSL room, though.

2. H1:LSC-MOD_RF9_AM_CTRL_GAIN was set to zero yesterday for some reason.

You can see this in the dataviewer plot top middle panel. I put it back to 1.

Images attached to this comment
H1 DetChar (DetChar, PEM)
borja.sorazu@LIGO.ORG - posted 19:21, Tuesday 17 November 2015 - last comment - 11:54, Friday 20 November 2015(23483)
60Hz glitch source at LHO identified and FIXED

(Borja, Vinny Roma)

This is a continuation of the work started yesterday here. Today, during maintenance, we worked all morning on the hunting of the 60Hz glitch noise and we can now confirm that the issue was identified and solved.

At  2015-11-17 17:10 (UTC) we arrived at the EndY station. We noticed an aircon unit outside of the building (although different model to that reported at Livingston) also used for cooling old clean rooms and no longer in use. We were sure that it was not running at the times that we observed the 60Hz bursts. We also noticed a fridge ON as we came in...more on this later.

We carried portable magnetometers similar to the ones used at the sites but plugged into oscilloscopes for portability. The area we concentrated most of our noise hunting was the electronics bay (EBAY) as from previous measurements we noticed that the bursts were stronger at the magnetometers located there (MAG_SUSRACK and MAG_SEISRACK) in comparison with MAG_VEA (see attached figure 'Comparison_MAGs_QUAD_SUM.png'). Looking at the spikes in more detail (see 'Zoom-spikes_Mag_VEA_and_EBAYs.png') we observe that while the spikes in MAG_VEA has a frequency of 60Hz, the spikes on MAG_EBAY_SUS and MAG__EBAY_SEI has double the frequency. This seems to be cause to a non-linear response of the transducer to the magnetic field, stronger in MAG_SEI than in MAG_SUS as both are identical sensors we assume the magnetic field from the spike is stronger at the SEI magnetometer.

Another clue that pointed to EBAY as the area of interest is the coherent plot attached of the MIC_EBAY and MIC_VEA_MINUSY with MAG_EBAY_SEI, we can clearly see correlations at 60Hz and harmonics being always stronger at MIC_EBAY. Notice however that we were never able to hear the burst so we assume the microphones pick them up electromagnetically.

In order to confirm that the bursts were actually real signals (instead of rack related issues) we swapped the axes of both magnetometers on EBAY as we observed they had different signal strenght. The change in the observed signal strength after the swap was compatible with the axes changes. Notice that we undid these changes after the morning work, so now is all back to normal.

Then we moved the portable magnetometer around the EBAY racks and noticed no strong magnetic noise anywhere with the exception of the 'PEM Endevco Power supply' which powers the accelerometers. The magnetic field around this box was very strong and MAG_EBAY_SEI is not far away from it. We also noticed that this was the only device connected to the wall AC power supply (see attached pictures) and this is also the case anywhere this PEM power supply is used.

We attach a time plot of EY_MAG_EBAY_SEI during the whole morning working period and we can see several things:

1) The time interval between bursts is much shorter and less regular than before (this was also observed previously when work was done at the End station). Compare attached plots from yesterday night ('Latest-60Hz_Bursts', very regular 85minutes separation between spikes) and today ('Morning_60Hz_timeplot_MAG', totally irregular with as short separation as 3 minutes).

2) The burst structure is different than the one previously related to 60Hz glitch noise (see here). For instance see the red circled area. During this time the vacuum cleaner was on near EBAY.

At this point we realized human activity with electric devices plugged to the wall at the station was involved with the generation of 60 Hz bursts although with a different signature to the bursts we knew and came to hunt.

Suddently for almost an hour (between hours 1.7 and 2.5 in plot 'Morning_60Hz_timeplot_MAG') we saw nothing. Then the burst became more spaced so after a while we tried to reproduce the vacuum cleaner burst signature by switching it on. The vacum cleaner was in the same room as the fridge and we noticed that the fridge was now turned OFF (we later learned that John and Bubba turned it OFF).

Then everything started to make sense...the fridge compresor only needs to be on when the temperature inside the fridge drops below a threshold which it can happen every 1.5 to 2 hours or longer depending on the environment temperature and quality of the fridge insulation. Notice that the interval between burst was shorter in summer than current months. Then the compresor is usually on for a few tens of minutes until the temperature is winthing desired range and then the compresor turns off. So in order to confirm the fridge as the cause of our 60Hz burst and glitches we tested turning it ON and we saw a burst (circled green on the previous plot at hour 3.5). And as we turned it OFF then the 60Hz burst dissapeared.

It appears that the fridge was ON the whole O1, this will no longer happen. But notice that any device drawing current from the mains seem to generate 60Hz bursts at least picked up by the magnetometers in EBAY, so soon we thought that maybe this is relared with the only device in that room that is plugged to the mains and that has a considerable Magnetic contamination...the 'PEM Endevco Power supply'.

So after lunch we went back to EndY station (arriving at UTC 23:07:00) with the intention of checking if unplugging the PEM Power Supply from the wall would be enough for the EBAY magnetometers not seeing the current draw by the fridge as this was turned on and off on 1 minute intervals for 3 times. For comparison we did the same test before with the Power supply still plugged and turned on. Unfotunatelly we see no difference between these two cases on MAG_EBAY_SEI as per attached plot 'Checking_PEM_Power_Supply_Coupling.png' magenta circle is with PEM Power Supply ON and brown is with the Power supply OFF. Interestingly however we can see a small spike at about UTC (23:34:00) when the turned off the Power supply and at 23:55:00 when we turned it back on.

Notice the spikes at the beginning correspond to our arrival to End station probably due to switching ON the shoe cleaner at the entrance and the desktop computer at EBAY.

Images attached to this report
Comments related to this report
borja.sorazu@LIGO.ORG - 13:43, Wednesday 18 November 2015 (23523)DetChar, PEM

As a follow up from yesterday entry. I attach a time plot of MAG_EBAY_SEIRACK at EndY for the last 19 hours after yesterday fix of the 60Hz bursts. We can see that the regular 60Hz burst are no longer happening. The only spike in that 19 hours period took place at UTC 2015-11-18 16:41:30 which is 8:41:30 am local time which agrees perfectly with the time at which several people went into the building to look at some ESD tripping related issues. Therefore as expected the spike is related to current draw at the building due to human activity.

Images attached to this comment
borja.sorazu@LIGO.ORG - 11:54, Friday 20 November 2015 (23596)DetChar

A final follow up on the FIX of the 60Hz glitches.

Now that LHO has been looked for quite some time I decided to compare Omicron triggers spectrograms before and after the fix. The evidence is clear that the regular 60Hz gliches are now gone.

Images attached to this comment
Displaying reports 62081-62100 of 85001.Go to page Start 3101 3102 3103 3104 3105 3106 3107 3108 3109 End