Displaying reports 58561-58580 of 83146.Go to page Start 2925 2926 2927 2928 2929 2930 2931 2932 2933 End
Reports until 13:41, Friday 29 January 2016
H1 SYS
keita.kawabe@LIGO.ORG - posted 13:41, Friday 29 January 2016 (25245)
We didn't see GPS anomaly

There was a report of GPS glitch as large as 13 microsec (http://www.itnews.com.au/news/satellite-failure-caused-global-gps-timing-anomaly-414237) starting around "January 26 12.49 am local time", presumably Mountain Standard Time, so it's probably around Jan 26 07:49 UTC, and was fixed by "6.10 am Mountain Standard Time".

I looked at the timing comparator for the cesium clock (H1:SYS-TIMING_C_MA_A_PORT_2_SLAVE_CFC_TIMEDIFF_1) as well as X end GPS receiver (H1:SYS-TIMING_X_FO_A_PORT_9_SLAVE_CFC_TIMEDIFF_3) and Y end GPS (H1:SYS-TIMING_Y_FO_A_PORT_9_SLAVE_CFC_TIMEDIFF_3).

(It seems like end station GPS units are connected to the second input of timing comparators at each end station at LLO, but here they are to the third input.)

Right plot shows 6-days, and the left one is 4 hours around the reported glitch, and I see no timing jump.

Images attached to this report
H1 General
cheryl.vorvick@LIGO.ORG - posted 12:10, Friday 29 January 2016 - last comment - 13:19, Friday 29 January 2016(25242)
Day Shift Mid-Day Update: 20:00UTC (12:00PT)

State of H1: locking but not making it to DRMI_Locked

Summary:

Comments related to this report
cheryl.vorvick@LIGO.ORG - 13:19, Friday 29 January 2016 (25244)

Update as of 21:12UTC (13:12PT)

  • H1 locked and went to Low Noise at 10W
  • the low power Low Noise lock is a test that needs about 30 minutes of lock time to analyze the data
  • the lock was unstable and broke lock
  • currently looking at changes
  • reverted those changes that were tests
  • reverted some changes logged mid-day today, and re-reverted back with Hugh's help
  • H1 is locking well, so expect to be relocked shortly, and look for cause of stability issues
H1 SEI (PEM, SYS)
hugh.radkins@LIGO.ORG - posted 11:36, Friday 29 January 2016 (25241)
HEPI Actuator Flushing Stand is running in the LHO Mechanical Room

We are pretty sure this added motor is a non issue as far as noise goes.  But, I'll let this run for a week before the configuration changes.  It is running under servo control and the level switch functions so it should shut itself off should a bad leak occur.  I have a nuisance drip on one of the hoses but am capturing that.

Otherwise, if you are in the Mechanical Room and see some major problem at the flushing stand, just hit the red button on the North facing enclosure cabinet.

H1 SEI
hugh.radkins@LIGO.ORG - posted 11:00, Friday 29 January 2016 - last comment - 15:51, Friday 29 January 2016(25238)
LHO ISI FF non-unity Gains moved to FMs--Greener Overviews

Re WP 7505

Making these gains unity greens the hardcoded medm making the state of the ISI look better by reducing the reds seen on the Overview screens.  There are still other reds seen in Sensor Correction and Blend sections of the Overview but greening or graying these out will be more of an medm programming pain.  I'm not sure I'll be able to 'fix' these...

The foton files have been committed.  I've acceptted the changes in the SDF OBSERVE.snaps (down.snap for the BS.)  I still need to accept these for the safe.snaps & the BS OBSERVE.snap.  I'll complete that after the meeting currently attending.

Meanwhile--Let's not restart any ISI FEs.

Comments related to this report
hugh.radkins@LIGO.ORG - 14:09, Friday 29 January 2016 (25246)

Here are conlog reported differences to record the gains.  If it is deemed a good idea to change the gain back just be sure to turn off the Match_G filter under the appropriate bank doing so in a reasonable order.  Gains changed to zero are on banks not being used so there is no reason to mess with them--Jim and I like to turn paths off as much as possible.

The foton files are committed.  JeffK grepped to extract the gains in the files and they are attached here too.  I just looked at them again and I very sure I did not make any typos in generating the fotons.  That is, the old gains (conlog) match the new gains in the fotons.

Images attached to this comment
hugh.radkins@LIGO.ORG - 14:42, Friday 29 January 2016 (25248)

I've captured all the ISI SDFs for safe, observe, & down.snaps.  These are committed to the svn except for the down (BS) as I don't know where that one is at the moment.

hugh.radkins@LIGO.ORG - 15:51, Friday 29 January 2016 (25254)

I've moved the ISI BS down.snap from the target area to the userapps area as h1isibs_down.snap and symbolic linked it back to the target area down.snap; it has been committed to the svn.

LHO General (OpsInfo)
corey.gray@LIGO.ORG - posted 10:54, Friday 29 January 2016 - last comment - 10:54, Friday 29 January 2016(25235)
LHO's Operator Team

After months of 24/7 work, had an opportunity to gather a majority of the LHO Operator Team during our Ops Meeting (Jim is photoshopped in since he was working as Commissioning Help during the evenings this week).

Thank you for all your work!

Images attached to this report
Comments related to this report
keith.thorne@LIGO.ORG - 10:27, Friday 29 January 2016 (25236)
You need to add Nutsinee's name to the list
corey.gray@LIGO.ORG - 10:54, Friday 29 January 2016 (25237)

WOW!  Thank you for catching that Keith!!  OK, it has been updated.  

H1 SUS
betsy.weaver@LIGO.ORG - posted 09:47, Friday 29 January 2016 (25234)
Weekly charge measurment status

FYI - I've been holding off on taking the ETM charge measurements since Cheryl has been hard at work to relock both yesterday and now today.  We assume it is better to keep plugging away at lock recovery since we've been on a dry spell for a few days.  We'll continue to look for an hour of dead time today through Tuesday.

H2 General
bubba.gateley@LIGO.ORG - posted 06:58, Friday 29 January 2016 (25233)
H-2 Electronics Bldg. Cooling System
The cooling system for the H-2 electronic building was repaired yesterday, (see FRS 4271), and is functioning correctly.
H1 TCS (TCS)
aidan.brooks@LIGO.ORG - posted 17:35, Thursday 28 January 2016 (25232)
Reset the CO2 AOM power supply in the mechanical room

The TCS AOM drivers had tripped. To reset them, I turned the AOM driver power supply (mezzanine in the mechanical room) off and then on again.

As much as I enjoyed the walk ou there, we need to be able to do this remotely.

H1 General
cheryl.vorvick@LIGO.ORG - posted 16:28, Thursday 28 January 2016 (25231)
Day Ops Summary:

Day Ops: 16:00-23:59UTC (08:00-16:00PT)

State of H1: unlocked, locking and making past DRMI, but not to Low Noise

Shift Summary:

Work Today:

Issues encoutered today - locking the X arm in IR:

Environmental deturants to locking:

H1 AOS (TCS)
alastair.heptonstall@LIGO.ORG - posted 14:50, Thursday 28 January 2016 (25230)
TCS CO2 laser photodiode calibration

The HgCdTe photodiodes on the TCS CO2 laser tables have had their calibration updated.  The outputs are now calibrated in volts at the PD.  I've stored the new calibrations in filter banks, such that both filters need to be turned on to get correct calibration of the channel and no other gain needs to be set.

The DC inputs have:

Filter 1) Convert from counts to volts

Filter 2) Divide by gain of 510 to give voltage at the photodiode

The AC inputs have:

Filter 1) Convert from counts to volts

Filter 2) De-whiten signal.  Initial whitening is AC coupled with a pole at 20Hz and a high frequency gain of 105dB.  We have reversed this with a filter that has high frequency gain of -105dB, a zero at 20Hz and a pole well below any frequency we care about at 0.01Hz (we didn't put the pole at 0Hz because we don't want this thing integrating continuously).

H1 AOS (TCS)
alastair.heptonstall@LIGO.ORG - posted 14:42, Thursday 28 January 2016 - last comment - 16:02, Wednesday 03 February 2016(25229)
TCS CO2 laser relative intensity noise measurement

[Alastair, Aidan]

Attached are some plots of RIN for the X and Y arm lasers.  There are now channels in the front end for RIN for in loop and out of loop photodiodes on each table.  Here we show the RIN and dark noise for both lasers.  The in loop photodiode for the Y-arm table is giving zero response so either there is a problem with it or the beam is mis-aligned.  I've only attached the data for the other 3 diodes.

The dark noise is consitent between all three diodes.  The RIN of the X-arm laser is approx 5x10^-7 at 20Hz.  The Y-arm laser is higher at 2x10^-7.  The Y-arm result is similar to the best we measured at Caltech (also attached).  It may be that the X arm is lower than we have previously measured due to the low noise enviroment.  The spectrums show no excess at low frequency such as would be attributed to air motion on the table, which is good news.  Also the in loop and out of loop diodes on the X-table show very similar spectrums which is good for any future intensity noise cancellation.

Images attached to this report
Comments related to this report
alastair.heptonstall@LIGO.ORG - 16:02, Wednesday 03 February 2016 (25366)

*****EDIT***** should say Y arm is 2x10^-6 RIN at 20Hz.

H1 ISC
filiberto.clara@LIGO.ORG - posted 12:12, Thursday 28 January 2016 - last comment - 12:49, Thursday 28 January 2016(25226)
Reshuffling of electronics in ISC-R3
Moved electronics to reflect new rack layout for ISC-R3 per D1001426-v10. This is to allow spacing for the new 2 omega auto-centering electronics. Work consisted of moving chassis a few U slots in the rack. All electronics remained on, and no cables were disconnected. Work will continue tomorrow to run field cables from CER to HAM6 racks. This will involve working over HAM6.

Fil C. & Ed M. & Daniel S.
Comments related to this report
evan.hall@LIGO.ORG - 12:49, Thursday 28 January 2016 (25227)

Around the same time, we noticed a shift in the dc offset of ASAIR 90 I&Q. Not surprising; we've seen this before when people work in or near the HAM6 rack. Jenne and I adjusted the digital ASAIR 90 I&Q offsets to compensate.

LHO VE
kyle.ryan@LIGO.ORG - posted 10:03, Thursday 28 January 2016 - last comment - 11:02, Friday 29 January 2016(25221)
X2-8 BT ion pump shut off ("shut down" on display) @ 0630 hrs. local
0915 -0955 hrs. local -> To and from X-end 

Pump won't start on either HV channel, gets to 500V then limits at 500ma -> Tempted to increase the default arc limit of 10 per minute but will consult with GammaVacuum first
Comments related to this report
kyle.ryan@LIGO.ORG - 10:55, Thursday 28 January 2016 (25225)
1020 - 1040 hrs local -> To and from X-end 

Consulted with Gamma Vacuum -> They advised not exceeding 20 arc/min setting -> I tried 15 - no help -> I also unplugged the HV cable from the controller but left the SafeConn connector connected and then enabled the HV which then came up to 7500V without a problem - meaning the controller is likely OK - more to come
scott.mccormick@LIGO.ORG - 11:02, Friday 29 January 2016 (25239)
What type of HV cable is in service? Gamma's cable or RG58 RED? Did you pull both types of cables to have one as a back up? 
H1 CDS
david.barker@LIGO.ORG - posted 17:57, Wednesday 27 January 2016 - last comment - 11:46, Wednesday 03 February 2016(25216)
Count of RFM IPC channels on H1 and L1

H1 has 30 sender RFM channels on each arm, of which only 26 have corresponding receiver(s). So 4 are being sent and no model is using the data.

L1 has 29 senders on the X-ARM (of which there are 26 receivers), and 30 senders on the Y-ARM (of which there are 26 receivers).

So the two sites are very close in number of sending channels.

Analysis details: The base number of potential senders was derived from the main IPC file, looking for RFM0 and RFM1 ipc types. This resulted in 30 for H1-X and H1-Y, and 42 for L1-X and L1-Y. Because the ipc file is only appended to during compilation, if it has not been cleanly regenerated recently it may overcount the number of sending channels.

For each channel, I searched the models' RCG generated IPC_STATUS.adl medm file for the channel name (e.g. H1LSC_IPC_STATUS.adl). Assuming that no two ipc channels share the same name, if I found the channel name in the adl file this means it is a running sender with a receiver. For the remaining possible senders without receivers (H1-X=4, H1-Y=4, L1-X=16, L1-Y=16) I looked for the channels in the top level simulink source files (e.g. /opt/rtcds/userapps/release/*/l1/models/l1*.mdl). This showed that all four channels on H1-X and H1-Y do have sending models, and for L1-X 3 of the 16 had sending models, and for L1-Y 4 of the 16 had sending models.

If we can possibly remove some of the RFM channels which are not being received, additional RFM channels can be added to the loop with no risk.

For H1 the sending channels with no receivers are:

Comments related to this report
jeffrey.kissel@LIGO.ORG - 11:03, Friday 29 January 2016 (25240)CAL, SEI
Tagging people interested in adding new (or rather, trading for) RFM channels.

SEI: IFO Basis SEI channels

CAL: Sending PCAL excitations to the corner.
brian.lantz@LIGO.ORG - 11:46, Wednesday 03 February 2016 (25350)
Dave,
Thanks for the count.
For the SUSpoint motion in the IFO basis, (see  ECR E1600028 , or  Integration Issue 1193 , or  Tech Doc T1500610 )

we need 2 RFM channels, 1 per arm for the ETMX SUS-WIT and ETMY SUS-WIT each to OAF in the corner.

For completeness, I note that we also need some PCIe channels from the top level of other 12
suspensions (3 IMCs, 3 SRMs, 3 PRMs, BS, ITMX, ITMY). 

These can replace the GS-13 X/Y signals now being used by OAF. Evidently the RFM senders for these are living in the PEM model at LLO. I do not know why it is done this way, but it may be related to the configuration of the FE machine for ISI at LLO.


ALSO (1) :

for more complete monitoring, it would be useful to also send the STS-2 X/Y signal from the end to OAF.

ALSO (2):
For Earthquake common mode control (still hypothetical) we would need to send the End X or Y STS-2 to the corner, and ALSO send the corner X/Y out to the ends.

Summary of RFM:
1 per arm from SUS to OAF (high priority) 
1 per arm from ISI-GND to OAF (med priority)
1 per arm from GND-ITMY X to End X and ITMY-Y to End Y (med priority)

NOTE- these signals don't need to be 16k. We want accurate data at 1 Hz and below, so 512 sample/sec would be fine. Thus, it is not crazy to think about ways to de-stress the RMF system (e.g. interleave several slow channels on one fast RFM connection, or something like this.)
Displaying reports 58561-58580 of 83146.Go to page Start 2925 2926 2927 2928 2929 2930 2931 2932 2933 End