40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 40m Log, Page 277 of 348 Not logged in
ID Date Author Type Category Subject
10995   Tue Feb 10 13:48:58 2015 manasaUpdateLSCProbable cause for headaches last night

I found the PSL enclosure open (about a feet wide) on the north side this morning. I am assuming that whoever did the X beatnote alignment last night forgot to close the door to the enclosure before locking attempts

 Quote: Unfortunately, we only had one good CARM offset reduction to powers of about 25, but then my QPD loop blew it. We spent the vast majority of the night dealing with headaches and annoyances.  Things that were a pain: If TRX is showing large excursions after finding resonance, there is no hope. These translate into large impulses while reducing the CARM offset, which the PRMI has no chance of handling. The first time aligning the green beat did not help this. For some reason, the second time did, though the beatnote amplitude wasn't increased noticibly.  NOTICE: We should re-align the X green beatnote every night, after a solid ASS run, before any serious locking work.  Afterwards, phase tracker UGFs (which depend on beatnote amplitude, and thereby frequency) should be frequently checked.  We suffered some amount from ETMX wandering. Not only for realigning between lock attempts, but on one occasion, with CARM held off, GTRX wandered to half its nominal value, leading to a huge effective DARM offset, which made it impossible to lock MICH with any reasonble power in the arms. Other times, simply turning off POX/POY locking, after setting up the beatnotes, was enough to significantly change the alignment.  IMC was mildly tempermental, at its worst refusing to lock for ~20min. One suspicion I have is that when the PMC PZT is nearing its rail, things go bad. The PZT voltage was above 200 when this was happening, after relocking the PMC to ~150, it seems ok. I thing I've also had this problem at PZT voltages of ~50. Something to look out for.  Other stuff: We are excited for the prospect of the FOL system, as chasing the FSS temperature around is no fun.  UGF servo triggering greatly helps the PRMI reacquire if it briefly flashes out, since the multipliers don't run away. This exacerbated the ALS excursion problem.  Using POPDC whitening made it very tough to hold the PRMI. Maybe because we didn't reset the dark offset...?

10996   Tue Feb 10 16:01:21 2015 manasaUpdateGeneralAUX X fiber coupled 72%

Plan C finally worked. We have 1.454mW of AUX X light at the PSL table (2mW incident on the fiber coupler).

Attached is the layout of the telescope.

What I did:

I stuck in Lens 1 (f=200mm) and measured the beam width after the focus of the lens at several points. I fit the data and calculated the beam waist and its position after this lens.

I used the calculated waist and matched it with an appropriate lens and target (fiber coupler) distance. I calculated the maximum coupling efficiency to be 77% for Lens 2 with f=50mm and the fiber coupler placed at 20cm from the waist of Lens1. I was able to obtain 72% coupling after putting the telescope together.

I locked the arms, ran ASS and brought back GTRX to its usual optimum value of ~0.5 counts after closing. We also have the X arm beatnote on the spectrum analyzer.

Notes:

There are still a couple of things to fix. The rejected beam from the beam sampler has to be dumped using a razor blade.

11006   Wed Feb 11 18:44:53 2015 manasaUpdateGeneralOptical fiber module

I have moved the optical fiber module for FOL to the PSL table. It is setup on the optical table right now for testing.

Once tests are done, the box will move to the rack inside the PSL enclosure.

While doing any beat note alignment, please watch out for the loose fibers at the north side of the PSL enclosure until they are sheilded securely (probably tomorrow morning).

11013   Thu Feb 12 12:16:04 2015 manasaUpdateGeneralFiber shielding

[Steve, Manasa]

The fibers around the PSL table were shielded to avoid any tampering.

11014   Thu Feb 12 12:23:21 2015 manasaUpdateGeneralWaking up the PDFR measurement system

[EricG, Manasa]

We woke up the PDFR measurement setup that has been sleeping since summer. We ran a check for the laser module and the multiplexer module. We tried setting things up for measuring frequency response of AS55.
We could not repeat Nichin's measurements because the gpib scripts are outdated and need to be revised.

PDFR diode laser was shutdown after this job.

11065   Wed Feb 25 11:01:05 2015 manasaUpdateComputer Scripts / ProgramsNew screen for FOL PID loop

Created a new medm screen C1ALS_FOL_PID.adl for FOL PID loop control in /medm/als/master/

This is not currently linked to the sitemap screen.

11075   Thu Feb 26 10:56:34 2015 manasaUpdateGeneralRunning cables

[Steve, Manasa]

We ran power cables and sma cables for the FOL fiber module from the PSL table to the IOO rack.

11078   Thu Feb 26 16:37:21 2015 manasaFrogsLSCRIP illegal power supply

No more illegal power supply at the LSC rack

The amplifiers are now being powered by the rack power supply through fuse blocks.

To make new connections, I shutdown the +/-15 V low noise power supplies. They were turned back ON after the work.

Quote:

### Is this your illegally installed HP bench power supply?

If so, or if not but you care about the signal that passes through these amplifiers, I suggest you remove this temporary power supply and wire the power from the rack power supplies through the fuse blocks and possibly use a voltage regulator.

In 24 hours, that power supply will be disconnected and the wires snipped if they are still there.

11079   Thu Feb 26 16:46:37 2015 manasaUpdateGeneralIOO rack power supply

I shutdown the +/-15V and the +/-24V sorensons on the IOO rack to connect the FOL RF PDs to the rack power supply.

They were turned back ON after the work. PMC and MC were relocked.

 Quote: [Steve, Manasa] We ran power cables and sma cables for the FOL fiber module from the PSL table to the IOO rack.

11101   Thu Mar 5 11:18:28 2015 manasaUpdateGeneralRF amplifier box

I pulled out the RF amplifier box from the IOO rack and swapped the amplifiers for FOL beat frequency amplification. The earlier gain of 62dB (ZFL500LN + ZFL500LN) was reduced to 40dB gain (ZFL500LN+ZFL2AD).

I also swapped one of the broken sma cables that was connecting the two amplifiers with a good one. Front ports of the module were relabeled and the box was put back on the rack.

During the course of this work, I had to turn OFF the green BBPDs on the PSL table to protect them and they have been powered up after putting the module back.

 Quote: As Koji found one of the spare channels of the ALS/FOL RF amplifier box nonfunctional yesterday, I pulled it out to fix it. I found that one of the sma cables did not conduct. It was replaced with a new cable from Koji. Also, I rearranged the ports to be consistent across the box, and re-labeled with the gains I observed.  It has been reinstalled, and the Y frequency counter that is using one of the channels shows a steady beat freq. I cannot test the amplitude of the green X beat at this time, as Koji is on the PSL table with the PSL shutter closed, and is using the control room spectrum analyzer. However, the dataviewer trace for the fine_phase_out_Hz looks like free swinging cavity motion, so its probably ok.

11102   Thu Mar 5 12:27:27 2015 manasaUpdateGeneralFOL fiber box on the PSL table

Working around the PSL table

I have put the FOL fiber box on the PSL table. The fibers carrying AUX and PSL light are connected and the RFPDs have been powered up. I can see the beat frequency on the frequency counters; but for some reason Domenica (that brings the frequency counter values on the medm screens) is not visible on the network even after hard reboot of the raspberry pi. I am neither able to ping nor ssh into the machine. I have to pull the module out and add a monitor cable to troubleshoot (my bad I should have left the monitor cable with the raspberry pi in the first place). Anyways, I have handed over the IFO to Q and will play with things again sometime later.

The fiber box on the PSL table is only left there temporariliy till I have things working. It will be stowed on the rack properly later.

In case someone wants the fiber box out of the PSL table, please make sure to power down the RFPDs using the black rocker switches on the side of the box and then disconnect the cables and fibers.

11110   Fri Mar 6 14:29:59 2015 manasaUpdateGeneralFOL troubleshooting

[EricQ, Manasa]

Domenica:
Since Domenica was not picking up an IP address and hence not responding to pings or ssh even after power cycling, I pulled it out from the IOO rack and connected it to a monitor. After a bunch of hit and trials, we figured out that the problem was related to the power adapter of the Rpi discussed here : http://www.raspberrypi.org/forums/viewtopic.php?f=28&t=39055

The power adapter has been swapped and this issue has been resolved. Domenica has been remounted on the IOO rack but left with the top lid off for the timebeing.

RF amplifier box:
The frequency counter was setup to read the beat frequency after amplification of the RFPD signals. The output as seen on the frequency counter screen as well as the epics values was intermittent. Also, locking the arms and changing the end laser frequencies did not change the frequency counter outputs. It looks like the RF amplifier is oscillating (Oscillating frequencies were ~107 MHz and 218 MHz) and the input circuit needs to be modified and the connections need better insulation.

As of now, I have connected the RFPD outputs to the frequency counter sans any amplification and we are able to get a readout of the beat frequency at > 40MHz (Frequency counter requires much higher amplitude signals for frequencies lower than that).

11123   Mon Mar 9 14:43:31 2015 manasaUpdateGeneralFOL troubleshooting

Figuring out the problem with frequency counter readouts:

 RF amplifier box: The frequency counter was setup to read the beat frequency after amplification of the RFPD signals. The output as seen on the frequency counter screen as well as the epics values was intermittent. Also, locking the arms and changing the end laser frequencies did not change the frequency counter outputs. It looks like the RF amplifier is oscillating (Oscillating frequencies were ~107 MHz and 218 MHz) and the input circuit needs to be modified and the connections need better insulation. As of now, I have connected the RFPD outputs to the frequency counter sans any amplification and we are able to get a readout of the beat frequency at > 40MHz (Frequency counter requires much higher amplitude signals for frequencies lower than that).

The frequency counter has 4 ranges of operation:
Range 1 : 1 - 40MHz
Range 2: 40 - 190MHz
Range 3: 190 - 1400MHz
Range 4: 1400 - 6000MHz

I set up the beat frequency readout in various configurations to troubleshoot and have recorded my observation (attachments). The amplifiers in all cases is just a single ZFL-500LN.

There seems to be a problem with the RF amplifier and the frequency counter when they are set together. I am not able to figure it out and stuck right here

Attachment 1: schematic for readout and corresponding observations

Attachment 2: Oscilloscope screen snapshot for schematic 3

Attachment 3: Spectrum analyzer screen snapshot for schematic 3

More info: RFPD used is Thorlabs FPD310 and frequency counter is Mini Circuits UFC-6000. The RF amplifier has decoupling capacitors soldered across the power supply.

Attachment 1: FOL_trouble.pdf
Attachment 2: IMAG0341.jpg
Attachment 3: IMAG0342.jpg
11127   Tue Mar 10 14:47:05 2015 manasaUpdatePSLPMC relocked

PMC was locked in a bad state. FSS slow actuator adjust was at ~ -0.7 and PZT voltage at ~45.

So I set these right by moving the appropriate sliders and relocked it. FSS slow actuator adjust brought back to zero and PZT voltage ~115. PMC trans after relock is 0.789.

11128   Tue Mar 10 17:48:07 2015 manasaUpdateGeneralFOL troubleshooting

[Koji, Manasa]

This problem was solved by changing the Frequency Counter range settings.

Frequency counter automatic range setting has been modified and now the range can be manually set depending on the input frequency. New codes have been written to do this. The scripts will be polished and wrapped up shortly.

Quote:

Figuring out the problem with frequency counter readouts:

 RF amplifier box: The frequency counter was setup to read the beat frequency after amplification of the RFPD signals. The output as seen on the frequency counter screen as well as the epics values was intermittent. Also, locking the arms and changing the end laser frequencies did not change the frequency counter outputs. It looks like the RF amplifier is oscillating (Oscillating frequencies were ~107 MHz and 218 MHz) and the input circuit needs to be modified and the connections need better insulation. As of now, I have connected the RFPD outputs to the frequency counter sans any amplification and we are able to get a readout of the beat frequency at > 40MHz (Frequency counter requires much higher amplitude signals for frequencies lower than that).

The frequency counter has 4 ranges of operation:
Range 1 : 1 - 40MHz
Range 2: 40 - 190MHz
Range 3: 190 - 1400MHz
Range 4: 1400 - 6000MHz

I set up the beat frequency readout in various configurations to troubleshoot and have recorded my observation (attachments). The amplifiers in all cases is just a single ZFL-500LN.

There seems to be a problem with the RF amplifier and the frequency counter when they are set together. I am not able to figure it out and stuck right here

Attachment 1: schematic for readout and corresponding observations

Attachment 2: Oscilloscope screen snapshot for schematic 3

Attachment 3: Spectrum analyzer screen snapshot for schematic 3

More info: RFPD used is Thorlabs FPD310 and frequency counter is Mini Circuits UFC-6000. The RF amplifier has decoupling capacitors soldered across the power supply.

11132   Wed Mar 11 15:35:38 2015 manasaUpdateGeneralWaking up the PDFR measurement system

I was around the 1Y1 rack today. Trials were done to get the PDFR of AS55.

 Quote: [EricG, Manasa] We woke up the PDFR measurement setup that has been sleeping since summer. We ran a check for the laser module and the multiplexer module. We tried setting things up for measuring frequency response of AS55. We could not repeat Nichin's measurements because the gpib scripts are outdated and need to be revised.  PDFR diode laser was shutdown after this job.

11145   Thu Mar 19 14:37:17 2015 manasaConfigurationIOOIMC relocked

The autolocker was struggling to lock the IMC. I disabled the autolocker and locked the IMC manually. It seems happy right now.

With PMC trans at 0.717 counts, the IMC trans sum is ~15230.

 Quote: The MC autolocker hasn't been so snappy recently, and has been especially fussy today. Previously, the mcup script was triggered immediately once the transmission was above a certain threshold. However, this could waste time if it was just an errant flash. Hence, I've added a 0.5 second delay and a second threshold check before mcup is triggered.  After breaking the lock 5ish times, it does seem to come back quicker.

11164   Tue Mar 24 10:53:30 2015 manasaUpdateGeneralScripts updated to the svn

I found that the scripts in FOL and PDFR directories were not in the svn. These were added to the svn.

11166   Tue Mar 24 15:22:12 2015 manasaUpdateComputer Scripts / ProgramsNew slow channels for FOL

[Koji, Manasa]

I have created new slow channels for FOL. To do so, I have edited the fcreadout.db file in Domenica and the C0EDCU.ini file in /chans/daq

Domenica and frame builder were restarted after the edits.

Koji has moved the following files from /opt/rtcds/caltech/c1/chans/daq/ to /opt/rtcds/caltech/c1/chans/daq/trash  as they are not being used anymore.

C0EDCU1.ini C1EDCU_X00.ini C1EDCU_X10.ini C1EDCU_X14.ini C1X00.ini C1X10.ini C1X99.ini

11189   Wed Apr 1 11:42:30 2015 manasaUpdateComputer Scripts / ProgramsPID script in python

Since none of us here are experts in pearl, I have put together a python script for a simple PID controller. This can be imported into any main scripts that will run the actual PID loop. The script, PID.py, exists in /scripts/general/

11199   Fri Apr 3 14:57:38 2015 manasaUpdateSUSBS oplev

The BS oplev has been misbehaving and kicking the optic from time to time since noon. The kicks are not strong enough to trip the watchdogs (current watchdog max counts for the sensors is 135).

I took a look at the spectrum of the BS oplev error in pit and yaw with both loops enabled while the optic was stable. There is nothing alarmingly big except for some additional noise above 4Hz.

I have turned the BS oplev servo OFF for now.

Attachment 1: BS_oplev_Apr3.png
11209   Wed Apr 8 21:10:55 2015 manasaUpdateGeneralWaking up the PDFR measurement system

I was poking around with the PDFR hardware today.

I moved the Agilent which had its screen projected on the monitor. I have put it back...but please verify the settings before using it for tonight.

11235   Wed Apr 22 11:48:30 2015 manasaSummaryGeneralDelay line frequency discriminator for FOL error signal

Since the Frequency counters have not been a reliable error signal for FOL PID loop, we will put together an analog delay line frequency dicriminator as an alternative method to obtain the beat frequency.

The configuration will be similar to what was done in elog 4254 in the first place.

For a delay line frequency dicriminator, the output at the mixer is proportional to $cos(\theta_{b})$ where $\theta_{b} = 2 \pi f_{b}L/v$

L - cable length asymmetry, fb - beat frequency and v - velocity of light in the cable.

The linear output signal canbe obtained for  $0< \theta_{b}<\pi$

For our purpose in FOL, if we would like to measure beat frequency over a bandwidth of 200MHz, this would correspond to a cable length difference of 0.5 m (assuming the speed of light in the coaxial cable is ~ 2x108m/s.

11236   Wed Apr 22 14:56:18 2015 manasaSummaryGeneralDelay line frequency discriminator for FOL error signal

[Koji, Manasa]

Since the bandwidth of the fiber PD is ~ 1GHz, we could design the frequency discriminator to have a wider bandwidth (~ 500MHz). The output from the frequency discriminator could then be used to define the range setting of the frequency counter for readout or may be even error signal to the PID loop.

A test run for the analog DFD with cable length difference of 27cm gave a linear output signal with zero-crossing at ~206MHz.

Detailed schematic of the setup and plot (voltage vs frequency) will be updated shortly.

11270   Mon May 4 10:21:09 2015 manasaSummaryGeneralDelay line frequency discriminator for FOL error signal

Attached is the schematic of the analog DFD and the plot showing the zero-crossing for a delay line length of 27cm. The bandwidth for the linear output signal obtained roughly matches what is expected from the length difference (370MHz) .

We could use a smaller cable to further increase our bandwidth. I propose we use this analog DFD to determine the range at which the frequency counter needs to be set and then use the frequency counter readout as the error signal for FOL.

Attachment 1: DFD.png
Attachment 2: DFD_resp.png
11272   Mon May 4 12:42:34 2015 manasaSummaryGeneralDelay line frequency discriminator for FOL error signal

Koji suggested that I make a cosine fit for the curve instead of a linear fit.

I fit the data to $V(f) = A + B cos(2\pi f_{b}L/v)$
where L - cable length asymmetry (27 cm) , fb - beat frequency and v - velocity of light in the cable (2*10m/s)

The plot with the cosine fit is attached.

Fit coefficients (with 95% confidence bounds):
A =      0.4177  (0.3763, 0.4591)
B =       2.941  (2.89, 2.992)

Attachment 1: DFD_cosfit.png
11280   Mon May 11 13:21:25 2015 manasaUpdateCDSc1lsp and c1sup not running

I found the c1lsp and c1sup models not running anymore on c1lsc (white blocks for status lights on medm).

To fix this, I ssh'd into c1lsc. c1lsc status did not show c1lsp and c1sup models running on it.

I tried the usual rtcds restart <model name> for both and that returned error "Cannot start/stop model 'c1XXX' on host c1lsc".

I also tried rtcds restart all on c1lsc, but that has NOT brought back the models alive.

Does anyone know how I can fix this??

c1sup runs some the suspension controls. So I am afraid that the drift and frequent unlocking of the arms we see might be related to this.

P.S. We might also want to add the FE status channels to the summary pages.

11281   Mon May 11 13:26:02 2015 manasaUpdateIMCMC_F calibration

The last MC_F calibration was done by Ayaka : Elog 7823

 Quote: And does anyone know what the MC_F calibration is?

11282   Mon May 11 14:08:19 2015 manasaUpdateCDSc1lsp and c1sup removed?

I just found out that c1lsp and c1sup models no more exist on the FE status medm screens. I am assuming some changes were done to the models as well.

Earlier today, I was looking at some of the old medm screens running on Donatella that did not reflect this modification.

 Quote: I found the c1lsp and c1sup models not running anymore on c1lsc (white blocks for status lights on medm). To fix this, I ssh'd into c1lsc. c1lsc status did not show c1lsp and c1sup models running on it. I tried the usual rtcds restart for both and that returned error "Cannot start/stop model 'c1XXX' on host c1lsc". I also tried rtcds restart all on c1lsc, but that has NOT brought back the models alive. Does anyone know how I can fix this?? c1sup runs some the suspension controls. So I am afraid that the drift and frequent unlocking of the arms we see might be related to this.   P.S. We might also want to add the FE status channels to the summary pages.

11283   Mon May 11 15:15:12 2015 manasaUpdateGeneralRan ASS for arms

Arm powers had drifted to ~ 0.5 in transmission.

X and Y arms were locked and ASS'd to bring the arm transmission powers to ~1.

11286   Tue May 12 12:04:41 2015 manasaUpdateGeneralSome maintenance

* Relocked IMC. I guess it was stuck somewhere in the autlocker loop. I disabled autolocker and locked it manually. Autolocker has been reenabled and seems to be running just fine.

* The X arm has been having trouble staying locked. There seemed to be some amount of gain peaking. I reduced the gain from 0.007 to 0.006.

*  I disabled the triggered BounceRG filter : FM8 in the Xarm filter module.  We already have a triggered Bounce filter: FM6 that takes care of the noise at bounce/roll frequencies. FM8 was just adding too much gain at 16.5Hz. Once this filter was disabled the X arm lock has been much more stable.
Also, the Y arm doesn't use FM8 for locking either.

11300   Mon May 18 14:46:20 2015 manasaSummaryGeneralDelay line frequency discriminator for FOL error signal

Measuring the voltage noise and frequency response of the Analog Delay-line Frequency Discriminator (DFD)

The schematic and an actual photo of the setup is shown below. The setup was checked to be physically sturdy with no loose connections or moving parts.

The voltage noise at the output of the DFD was measured using an SR785 signal analyzer while simultaneously monitoring the signal on an oscilloscope.

The noise at the output of the DFD was measured for no RF input and at several RF input frequencies including the zero crossing frequency and the optimum operating frequency of the DFD (20MHz).

The plot below show the voltage noise for different RF inputs to the DFD. It can be seen that the noise level is slightly lower at the zero crossing frequency where the amplitude noise is eliminated by the DFD.

I also did measurements to obtain the frequency response of the setup as the cable length difference has changed from the prior setup. The cable length difference is 21cm and the obtained linear signal at the output of the DFD extends over ~ 380MHz which is good enough for our purposes in FOL. A cosine fit to the data was done as before. //edit- Manasa: The gain of SR560 was set to 20 to obtain the data shown below//

Fit Coefficients (with 95% confidence bounds):
a =     -0.8763  (-1.076, -0.6763)
b =       3.771  (3.441, 4.102)

Data and matlab scripts are zipped and attached.

Attachment 4: DFD.zip
11309   Tue May 19 11:50:52 2015 manasaUpdatePEMNo noticeable effect from M4.0 earthquake

There was an earthquake: M4.0 - 40km SSW of South Dos Palos, California

No noticeable effects on the IFO. MC did not lose lock; however the arms did unlock.

9409   Tue Nov 19 11:56:10 2013 manasa, jenne, ericQUpdateLSCPRM- OSEM side ccd camera is in place

Quote:

 Quote: Can't we somehow hook up this camera to the MUX with the movie mode? I think both the MUX and the sensoray are compatible with the color video signal. Only the old CRT is B/W.

Watek ccd with Tamron lens is hooked up to MUX

This set up close to the viewport glass! Please be careful!

Video captures when power recycling cavity is locked (videos 1 & 2) and flashing (video 3). Arms stayed misaligned.

1. CH1 and CH2 are loooking at PRM front and back faces. CH3 and CH4 are looking at POP and REFL

2. CH1 and CH2 are loooking at PRM front and back faces. CH3 and CH4 are looking at the ITMs

3. CH1 and CH2 are loooking at PRM front and back faces. CH3 and CH4 are looking at POP and REFL

9156   Tue Sep 24 20:43:45 2013 masayukiSummarySUSoptical levers centering

I centered optical levers of ITMX,BS,ETMY. I also change the position of optical levers of ITMX, ETMY, ITMY, BS on Friday night(9/21), of ITMX, ETMY, BS on Monday night. Both are around 6:00 ~ 7:00.But centering on Monday was totally wrong, because I centered with not good IFO alignment.

The attachment is the 5 days trend of the opt lev of ITMX. First gap is alignment on Friday and Second gap is the alignment on Monday. Now I centered after  locking the FPMI.

The attachment 2 is the last 6 hours data.  The gap on 9/25 00:00 and 1:30(UTC)  is because the alignment of the cavity and the last gap is because of  centering of the optical lever.

Attachment 1: Screenshot-Untitled_Window.png
Attachment 2: Screenshot-Untitled_Window-1.png
9183   Tue Oct 1 17:14:53 2013 masayukiUpdateGreen LockingALS servo filters modified

[Manasa, Masayuki]

[revised at 10/1 pm 5:00]

As we mentioned in previous entry (elog#9171), the phase margin of ALS control was at most 20 degree. We modified the filter of C1ALS_XARM and C1ALS_YARM. The OLTF is in attachment1. Now the phase margins of both arms are more than 35 degree. I modified the FM5 filters of both servo.

FM5 filter is the filter for the phase compensation. It had the one pole at 1000 Hz and one zero at 1Hz. As you can see in attachment2, it start to lose the phase at 50 Hz. But the UGF of our ALS control loop is higher than 100 Hz, so I changed the pole from 1 kHz to 3 kHz in order to get more phase margin at UGF. The new servo have 10dB larger gain than previous filter at higer than 1kHz, but the control loop do nothing in that region, so it's no problem.

We have phase lag between 2 arms. I used same filters for both arms, so I'm wondering where these phase lag came from.

Attachment 1: OLTF.pdf
Attachment 2: filter_change.pdf
9197   Thu Oct 3 10:29:03 2013 masayukiUpdateGreen LockingNew ALS autolocker flowchart

[Manasa, Masayuki]

We made a new flowchart of ALS autolocker. We added the additional step to find the beat note frequency. We have to find a way to read the PSL temperature. By reading the PSL temperature we can decide the sweep range for the end green laser temperature with the curve which measured in previous measurement (in this entry)

We have three thresholds of error signal. One is the threshold for checking the arms are stabilized or not. It should be some hundreds count. Another threshold is to check that the suspensions are not kicked. This should be some thousands counts (in flow chart, it is 2K counts). The other is to check the optimal servo gain. If the servo gain is too high, the UGF is also too high and we will not have enough gain margin. The error signal start to oscillate at the UGF. We will check this oscillation and find the optimal gain. In flow chart this threshold is 1K counts.

Attachment 1: flowchart.pdf
9321   Thu Oct 31 00:06:45 2013 masayukiUpdateComputer Scripts / Programscds fft,tf,offsets

I wrote the scripts for cdsutils.

1. fft

usage: fft.py [-h] [-c N_CYCL] [-a N_AVG] freq channel [channel ...]

Measures the frequency content of one or more NDS channels
at the specified frequecy.
The measurement results are  magnitude, phase, real part imaginary part, and the standard deviation of the real and imaginary parts.

positional arguments:
freq        measurement frequency
channel     list of measurement channel

optional arguments:
-h, --help  show this help message and exit
-c N_CYCL   define number of cycles. Default is 10
-a N_AVG    define number of average. Default is 100

2. tf

usage: tf.py [-h] [-c N_CYCL] [-a N_AVG] [--dB] freq input output

Measures the transfer funtion of one NDS channels pair  at the specified frequecy.
The measurement results are the coherence, magnitude, phase, real part, imaginary part, and the standard deviation of the real and imaginary parts.

positional arguments:
freq        measurement frequency
input       list of measurement input channel
output      list of measurement output channel

optional arguments:
-h, --help  show this help message and exit
-c N_CYCL   define number of cycles. Default is 10
-a N_AVG    define number of average. Default is 100
--dB        print the amplitude in dB

3.offsets

usage: offset.py [-h] [-t SECONDS] filterbank [filterbank ...]

Zero the offset of one or more filterbank. Take average of OUT16 channel, and put (-1 * average / gain) into offset.  After change offsets, it will turn on the offset.
example usage) offset -d 25 C1:LSC-AS55_Q C1:LSC-AS55_I

positional arguments:
filterbank  list of filterbank to zero offset

optional arguments:
-h, --help  show this help message and exit
-t SECONDS  define the averaging time. default value is 10

I put these scripts in /opt/rtcds/cdsutils/trunk/lib/cdsutils.
I couldn't put them into cds library, but I will left tomorrow to Japan...

By the way,

I modified the LSCoffset script  (script)/LSC/LSCoffsets.py.

usage: LSCoffsets.py [-h] [-d SECONDS] [--PDlist]

Zero the offsets of LSC PDs. During taking average, we will close the PSL and green shutter. After zeroing, it will turn on the offsets switch.
example usgae) LSCoffset2.py -d 20

optional arguments:
-h, --help  show this help message and exit
-d SECONDS  define the averaging time. default value is 10
--PDlist    print PD list for LSC and exit

i made new directory 'offset_backup' for old offset script. I move all old offset script into there.

But unfortunately that cannot use right now, because cds offsets script is not available yet...

2718   Sun Mar 28 17:28:26 2010 matt, kiwamuUpdateGreen Lockingfrequency discriminator for green PLL

Last Friday, Matt made a frequency discriminator circuit on a bread board in order to test the idea and study the noise level. I think it will work for phase lock acquisition of Green locking.

As a result a response of 100kHz/V and a noise level of 2uV/rtHz @ 10Hz are yielded. This corresponds to 0.2Hz/rtHz @ 10Hz.

The motivation of using frequency discriminators is that  it makes a frequency range wider and easier for lock acquisition of PLLs in green locking experiment.

For the other possibility to help phase lock acquisition, Rana suggested to use a commercial discriminator from Miteq.

(principle idea)

The diagram below shows a schematic of the circuit which Matt has built.

Basically an input signal is split into two signals right after the input, then one signal goes through directly to a NAND comparator.

On the other hand another split signal goes through a delay line which composed by some RC filters, then arrive at the NAND comparator with a certain amount of delay.

After going through the NAND comparator, the signal looks like a periodic pulses (see below).

If we put a signal of higher frequency we get more number of pulses after passing through the NAND.

Finally the pulse-signal will be integrated at the low pass filter and converted to a DC signal.

Thus the amplitude of DC signal depends on the number of the pulses per unit time, so that the output DC signal is proportional to the frequency of an input signal.

(result)

By putting a TTL high-low signal, an output of the circuit shows 100kHz/V linear response.

It means we can get DC voltage of 1 V if a signal of 100kHz is injected into the input.

And the noise measurement has been done while injecting a input signal. The noise level of 0.2Hz/rtHz @ 10 Hz was yielded.

Therefore we can lock the green PLL by using an ordinary VCO loop after we roughly guide a beat note by using this kind of discriminator.

Attachment 1: DSC_1407.JPG
Attachment 2: FD.png
Attachment 3: FDnoise.png
11257   Sun Apr 26 20:10:10 2015 max isiHowToGeneralSummary pages

I have set up new summary pages for the 40m: http://www.ligo.caltech.edu/~misi/summary/
This website shows plots (time series, spectra, spectrograms, Rayleigh statistics) of relevant channels and is updated with new data every 30 min.

The content and structure of the pages is determined by configuration files stored in nodus:/users/public_html/gwsumm-ini/ . The code looks at all files in that directory matching c1*.ini. You can look at the c1hoft.ini file to see how this works. Besides, a quick guide to the format can be found here http://www.ligo.caltech.edu/~misi/iniguide.pdf

Please look at the pages and edit the config files to make them useful to you. The files are under version control, so don’t worry about breaking anything.

11279   Mon May 11 12:17:19 2015 max isiHowToGeneralSummary pages

I have created a wiki page with introductory info about the summary page configuration: https://wiki-40m.ligo.caltech.edu/Daily summary help

We can also use that to collect tips for editing the configuration files, etc.

 Quote: I have set up new summary pages for the 40m: http://www.ligo.caltech.edu/~misi/summary/ This website shows plots (time series, spectra, spectrograms, Rayleigh statistics) of relevant channels and is updated with new data every 30 min. The content and structure of the pages is determined by configuration files stored in nodus:/users/public_html/gwsumm-ini/ . The code looks at all files in that directory matching c1*.ini. You can look at the c1hoft.ini file to see how this works. Besides, a quick guide to the format can be found here http://www.ligo.caltech.edu/~misi/iniguide.pdf Please look at the pages and edit the config files to make them useful to you. The files are under version control, so don’t worry about breaking anything. Do let me know if you have any questions (or leave a comment in the pages).

384   Mon Mar 17 18:30:48 2008 mevansConfigurationPEMAdaptive Filtering
It seems that adaptive filtering can achieve results similar to those of the MISO FIR Wiener (entry 369). The adaptive code simulates real-time operation, but uses the same data used by Rana for the Wiener filter. I ran the adaptive filter over the data 100 times to ensure that it was well trained... maybe too well.
394   Sat Mar 22 22:39:02 2008 mevansSummaryCDSDirect Form 2 filters are bad
Here I show a comparison between the filter algorithm currently used in LIGO (Direct Form II), and an alternative algorithm designed to reduce numerical noise. The input signal is

x = sin(2 * pi * t) + 1e-9 * sin(2 * pi * (fs / 4) * t);

where fs = 16384 is the sample rate. The filter is a 4th order notch at 1Hz (f_poles = f_zeros = 1Hz, Q_poles = 1, Q_zeros = 1e6). It is clear that the DF2 algorithm produces a noise floor that is, for this simple filter, 1e-11 / rtHz smaller than the input drive amplitude (see plots). That should probably be scary given how many second-order-sections we run our signals through. The low-noise form does a somewhat better job. The low-noise algorithm has the same memory and computational requirements as DF2, and our CDS guys have the code in hand. I suggest we start testing soon.

(The code is included below. You will need my Matlab library to run the top level test script.)
Attachment 1: low-noise_filtering.png
Attachment 2: low-noise_zoom.png
Attachment 3: FiltRT.zip
395   Sun Mar 23 00:43:08 2008 mevansHowToGeneralOnline Adaptive Filtering
I wrote a short document about the OAF running on the ASS. Since there is no BURT setup, I put a script in /cvs/cds/caltech/scripts to help with setting initial parameters: upass.
2728   Mon Mar 29 15:19:33 2010 mevansUpdateGreen Lockingfrequency discriminator for green PLL

Thanks for the great entry!

In order to make this work for higher frequencies, I would add Hartmut's suggestion of a frequency dividing input stage.  If we divide the input down by 100, the overall range will be about 200MHz, and the noise will be about 20Hz/rtHz.  That might be good enough... but we can hope that the commercial device is lower noise!

 Quote: Last Friday, Matt made a frequency discriminator circuit on a bread board in order to test the idea and study the noise level. I think it will work for phase lock acquisition of Green locking. As a result a response of 100kHz/V and a noise level of 2uV/rtHz @ 10Hz are yielded. This corresponds to 0.2Hz/rtHz @ 10Hz. The motivation of using frequency discriminators is that  it makes a frequency range wider and easier for lock acquisition of PLLs in green locking experiment.

4442   Fri Mar 25 01:27:29 2011 mevansFrogsGreen Lockingdigital frequency counting

Today we tried the Schmitt trigger DFD, and while it works it does not improve the noise performance.  At least part of our problem is coming from the discrete nature of our DFD algorithm, so I would propose that an industrious day job person codes up a new DFD which avoids switching.  We can probably do this by mixing the input signal (after high-passing) with a time-delayed copy of itself... as we do now, but without the comparator.  This has the disadvantage of giving an amplitude dependent output, but since we are working in the digital land we can DIVIDE.  If we mix the signal with itself (without delay) to get a rectified version, and low-pass it a little, we can use this for normalization.  The net result should be something like:

output = LP2[ s(t) * s(t - dt) / LP1[ s(t) * s(t) ]],

where s(t) is the high-passed input and LP is a low-pass filter.  Remember not to divide by zero.

6314   Fri Feb 24 16:10:48 2012 mikeUpdateComputersPyNDS and a Plot

Power Spectral Density plot using PyNDS, comparing 5 fast data channels for ETMX.

**EDIT** Script here:

import nds
import numpy as np
import matplotlib.pyplot as plt
import time
daq=nds.daq('fb', 8088)
channels=daq.recv_channel_list()
e=0
start=int(time.time()-315964819)
rqst=['C1:SUS-ETMX_SENSOR_UR','C1:SUS-ETMX_SENSOR_UL','C1:SUS-ETMX_SENSOR_LL','C1:SUS-ETMX_SENSOR_LR','C1:SUS-ETMX_SENSOR_SIDE']    #Requested Channels
for c in channels:
if c.name in rqst:
daq=nds.daq('fb', 8088)
data=daq.fetch(start-100, start, c.name)
vars()['psddata'+str(e)], vars()['psdfreq'+str(e)]=plt.psd(data[0],NFFT=16384,Fs=c.rate)
vars()['label'+str(e)]=c.name
e+=1
plt.figure(1)
plt.clf()
plt.title('PSD Comparison')
plt.grid(True, which='majorminor')
plt.xlabel(r'Frequency $Hz$')
plt.ylabel(r'Decibels $\frac{dB}{Hz}$')
for x in np.arange(0,e):
plt.loglog(psdfreq0, 10*vars()['psddata'+str(x)], label=vars()['label'+str(x)])
plt.legend()
plt.show()

Attachment 1: PSD_Comparison.png
3060   Wed Jun 9 19:47:08 2010 nancyUpdatePEMlead balls on concrete

Quote:

 Quote: Valera and I put the 2 Guralps and the Ranger onto the big granite slab and then put the new big yellow foam box on top of it. There is a problem with the setup. I believe that the lead balls under the slab are not sitting right. We need to cut out the tile so the thing sits directly on some steel inserts. You can see from the dataviewer trend that the horizontal directions got a lot noisier as soon as we put the things on the slab.

The tiles were cut out in 1.5" ID circle to insure that the 7/16" OD lead balls would not touch the tiles on Wednesday, May 26, 2010

Granite surface plate specifications: grade B, 18" x 24" x 3" , 139 lbs

These balls and granite plate were removed by  Rana in entry log #3018 at 5-31-2010

I tried to calculate the frequency of resonance using Rayleigh's method.  approximated the geometry of lead to be that of a perfect cylinder, and  the deformation in the lead by the deflection in a cantilever under  a shear strain.

this rough calculation gives an answer of 170Hz and depends on the dimensions of each lead, number of leads, and mass of the granite. But the flaw pointed out is that this calculation doesnot depend on the dimension of the granite slab, nor on the exact placing of the lead spheres with respect toteh COM of the slab.

I will put up the calculations details later, and also try to do a FEM analysis of the problem.

BTW, latex launched this new thing for writing pdfs. doesnot require any installations.  check  http://docs.latexlab.org

3081   Wed Jun 16 18:12:16 2010 nancyConfigurationComputers40MARS

i added my laptop's mac address to teh martian at port 13 today.

3101   Wed Jun 23 11:31:12 2010 nancyUpdateWIKI-40M UpdateWeekly Update

This week I attended a whole lot of orientations, lectures, and meetings related to SURF. Done with general and laser safety training.

read Nergis' thesis for, and other material on WFS.

got confused with how the sidebands and shifted carrier frequencies are chosen for the Interferometer, read initial chapters of Regehr's thesis for teh same.

Made a plan for proceeding with the WFS work through discussions with Koji.

Understood the MC cavity and drew a diagram for it and the sensors.

Did Calculations for Electric field amplitudes inside and outside the MC cavity.

Saw the hardware of the WFS and QPD inside, and their routes to computers. Figured out which computer shows up the conditioned data from teh sensors.

Tried calculating the cavity axis for MC using geometry and ray tracing. Too complicated to be done manually.

Read some material (mainly Seigman) for physics of calculating the eigen-axis of the MC cavity with mirrors mis-aligned. Will calculate that using simulations, using the ABCD matrices approach.