40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 40m Log, Page 60 of 341 Not logged in
ID Date Author Type Category Subject
4217   Fri Jan 28 09:03:38 2011 AidanSummaryGreen LockingDigital Frequency Discriminator

 Quote: That's some pretty fast work! I thought we would be taking up to a week to get that happening. I wonder what's the right way to measure the inherent frequency noise of this thing? Also, should the comparator part have some hysteresis (ala Schmidt trigger) or is it best to just let it twirl as is? Is it sensitive to DC offsets on the input or is there a high pass filter? What's the correct low pass filter to use here so that we can have a low phase lag feedback to the ETM?

We could try inputing a 4kHz carrier modulated width a depth of a few Hz at a modulation frequency of F1. Then we could take an FFT of the output of the discriminator and measure the width of the peak at F1 Hz. This seems like an arduous way to measure the frequency noise at a single frequency though.

It'll definitely be sensitive to DC offsets but there is already a filter bank on the INPUT filter so we can shape that as necessary. We could probably band-pass that from [4.5 - 5.3kHz] (which would correspond to a range of [73,87] MHz into a 2^14 frequency divider.

4218   Fri Jan 28 10:27:46 2011 Aidan, JoeSummaryGreen LockingDigital Frequency Discriminator - calibration

One more thing ... we can calibrate the output of the LP filter to give a result in Hz with the following calibration:

LP_OUT = -1/(2*dt)*(LP_IN -1), where dt is 1/16384, the delay time of the delayed path.

Therefore LP_OUT = -8192*(LP_IN-1).

4259   Tue Feb 8 10:23:02 2011 AidanSummaryGreen LockingDigital Frequency Discriminator - reference

Here's the reference for the self-reference frequency detection idea. See Figure 2.

http://www.phys.hawaii.edu/~anita/new/papers/militaryHandbook/mixers.pdf

4227   Sun Jan 30 17:15:09 2011 AidanSummaryGreen LockingDigital Frequency discriminator - frequency noise

I've had a go at trying to estimate the frequency noise of the digital frequency discriminator (DFD). I input a 234.5Hz (0.5Vpp) signal from a 30MHz function generator into the ADC. The LP output of the DFD measured 234.5Hz. However, this signal is clearly modulated by roughly +/- 0.2Hz at harmonics of 234.5Hz (as you can see in the top plot in the dataviewer screenshot below). So the frequency noise can be estimated as rms of approximately 0.2Hz.

This is supported by taking the spectra of the LP output and looking at the RMS. Most of the power in the RMS frequency noise (above the minimum frequency) comes from the harmonics of the input signal and the RMS is approximately 0.2Hz.

I believe this stems from the rather basic LP filter (three or four poles around 10Hz?) that is used in the LP filter to remove the higher frequency components that exist after the mixing stage. (The currently loaded LPF filter is not the same as the saved one in Foton - and that one won't load at the moment, so I'm forced to remember the shape of the current filter).

The attached screen capture from data viewer shows the LP_OUT hovering around 234.5Hz.

4213   Thu Jan 27 17:12:02 2011 Aidan, JoeSummaryGreen LockingDigital Frequency to Amplitude converter

Joe and I built a very simple digital frequency to amplitude converter using the RCG. The input from an ADC channel goes through a filter bank (INPUT), is rectified and then split in two. One path is delayed by one DAQ cycle (1/16384 s) and then the two paths are multiplied together. Then the output from the mixer goes through a second filter bank (LP) where we can strip off twice the beat frequency. The DC output from the LP filter bank should be proportional to the input frequency.

Input Channel: C1:GFD-INPUT_xxx

Output Channel: C1:GFD-LP_xxx

Joe compiled the code and we tested it by injecting a swept sine [100, 500]Hz in the input filter bank. We confirmed that output of the LP filter bank changed linearly as a function of the input frequency.

The next thing we need to do is add a DAC output. Once that's in place we should inject the output from a 4kHz VCO into the ADC. Then we can measure the transfer function of the loop with an SR785 (driving the VCO input and looking at the output of the DAC) and play around with the LP filter to make sure the loop is fast enough.

The model is to be found here:

The attached figures show the model file in Simulink and a realtime dataviewer session with injecting a swept sine (from 500Hz to 100Hz) into the INPUT EXC channel. We've had some frame builder issues so the excitation was not showing on the green trace and, for some reason, the names of the channels are back to front in dataviewer (WTF?), - the lower red trace in dataviewer is actually displaying C1:GFD-LP_OUT_DAQ, but it says it is displaying C1:GFD-INPUT_OUT_DAQ - which is very screwy.

However, the basic principle (frequency to amplitude) seems to work.

9353   Wed Nov 6 14:47:41 2013 SteveFrogsLSCDin connectors added at 1Y2

The north side of the LSC rack is full. I installed more DIN connectors with fuses on the south side of the rack 1Y2

The access to this may be a little bit awkward. You just remove the connector, wire it and put it back in.

8332   Fri Mar 22 19:46:29 2013 KojiSummaryLSCDiode impedance test result

I've tested Perkin-Elmer InGaAs PDs at OMC Lab.

- The diode impedances were measured with the impedance measurement kit. Reverse bias of 5V was used.

- Diode characteristics were measured between 10MHz and 100MHz.

- 4-digit numbers are SN marked on the can

- Ls and Rs are the series inductance and resistance

- Cd is the junction capacitance.

- i.e. Series LCR circuit o--[Cd]--[Ls]--[Rs]--o

C30665GH, Ls ~ 1nH

0782 Perkin-Elmer, Rs=8.3Ohm, Cd=219.9pF
1139 Perkin-Elmer, Rs=9.9Ohm, Cd=214.3pF
0793 Perkin-Elmer, Rs=8.5Ohm, Cd=212.8pF

C30642G, Ls ~ 12nH

2484 EG&G, Rs=12.0Ohm, Cd=99.1pF
2487 EG&G, Rs=14.2Ohm, Cd=109.1pF
2475 EG&G glass crack, Rs=13.5Ohm, Cd=91.6pF
6367 ?, Rs=9.99Ohm, Cd=134.7pF
1559 Perkin-Elmer, Rs=8.37Ohm, Cd=94.5pF
1564 Perkin-Elmer, Rs=7.73Ohm, Cd=94.5pF
1565 Perkin-Elmer, Rs=8.22Ohm, Cd=95.6pF
1566 Perkin-Elmer, Rs=8.25Ohm, Cd=94.9pF
1568 Perkin-Elmer, Rs=7.83Ohm, Cd=94.9pF
1575 Perkin-Elmer, Rs=8.32Ohm, Cd=100.5pF

C30641GH, Perkin Elmer, Ls ~ 12nH

8983 Perkin-Elmer, Rs=8.19Ohm, Cd=25.8pF
8984 Perkin-Elmer, Rs=8.39Ohm, Cd=25.7pF
8985 Perkin-Elmer, Rs=8.60Ohm, Cd=25.2pF
8996 Perkin-Elmer, Rs=8.02Ohm, Cd=25.7pF
8997 Perkin-Elmer, Rs=8.35Ohm, Cd=25.8pF
8998 Perkin-Elmer, Rs=7.89Ohm, Cd=25.5pF
9000 Perkin-Elmer, Rs=8.17Ohm, Cd=25.7pF

Note:  Calculated Ls&Rs of straight wires
1mm Au wire with dia. 10um -> 1nH, 0.3 Ohm
20mm BeCu wire with dia. 460um -> 18nH, 0.01 Ohm

10610   Wed Oct 15 17:09:49 2014 manasaUpdateGeneralDiode laser test preparation

[EricG, manasa]

The He-Ne laser oplev setup was swapped with a fiber-coupled diode laser from W Bridge. The laser module and its power supply are sitting on a bench in the east side of the SP table.

10651   Wed Oct 29 18:07:28 2014 manasaUpdateGeneralDiode laser test preparation

I ran 3 BNC cables from the SP table to 1X7 rack so that we can have 16 bit channels for the Ontrak PD that will be used to test oplev lasers. The BNC cables are plugged to the Ch 29, 30 & 31 that were already created for this purpose (elog 10488)

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.)
11791   Thu Nov 19 17:06:57 2015 KojiConfigurationCDSDisabled auto-launching RT processes upon FE booting

We want to startup the RT processes one by one on boot of FE machines.

Therefore /diskless/root/etc/rc.local on FB was modified as follows. The last sudo line was commented out.

for sys in $(/etc/rt.sh); do #sudo -u controls sh -c ". /opt/rtapps/rtapps-user-env.sh && /opt/rtcds/cal\ tech/c1/scripts/start${sys}"

    # NOTE: we need epics stuff AND iniChk.pl in PATH     # we use -i here so that the .bashrc is sourced, which should also     # source rtapps and rtcds user env (for epics and scripts paths)

    # commented out Nov 19, 2015, KA     # see ELOG 11791 http://nodus.ligo.caltech.edu:8080/40m/11791     # sudo -u controls -i /opt/rtcds/caltech/c1/scripts/start{sys} done 14474 Tue Mar 5 15:56:27 2019 gautamSummaryTip-TIltDiscussion points about TT re-design Chub, Koji and I have been talking about Udit's re-design. Here are a few points that were raised. Chub/Koji can add to/correct where necessary. Summary is that this needs considerable work before we can order the parts for a prototype and characterize it. I think the requirements may be stated as: 1. The overall pendulum length should be similar to that of the SOS, i.e. ~0.3m (current length is more like 0.1m) such that the eigenfrequencies are lowered to more like ~1 Hz. Mainly we wan't to avoid any overlap with the stack eigenmodes. This may require an additional stiffening piece near the top of the tower as we have for the SOS. What is a numerical way to spec this? 2. The center of the 2" optic should be 6" from the table. 3. The mass of the optic + holder should be similar to the current design so we may use the same suspension wires (I believe they are a different thickness than that used for the SOS). 4. Ensure we can extract any transmitted beams without clipping. 5. Fine pitch adjustment capablity should be yyy mrad (20mrad?). 6. We should preserve the footprint of the existing TTs, given the space constraints in vacuum. Moreover, we should be able to use dog-clamps to fix the tower in place, so the base plate should be designed accordingly. 7. Keep the machining requirements as simple as possible while achieving the above requirements- i.e. do we really need rounded optic holder? Why not just rectangular? Similarly for other complicated features in the current design. Some problems with Udit's design as it stands: 1. I noticed that the base of the TT and the center of the 2" optic are 4" separated. The SOS cage base and center of 3" optic are separated by 6". Currently, there is an adaptor piece that raises the TT height to match that of the SOS. If we are doing a re-design, shouldn't we just aim for the correct height in the first place? 2. Udit doesn't seem to have taken into account the torque due to the optic+holder in the pitch balancing calculations he did. Since this is expected to be >> that of any rod/screw we use for fine pitch balancing, we need to factor that into the calculation. 3. For the coarse pitch adjustment, we'd need to slide the wire clamping piece relative to the optic holding piece. Rather than do this stochastically and hope for the best, the idea was to use a threaded screw to realize this operation in a controlled way. However, Udit's design doesn't include the threaded hole. 4. There are many complicated machining features which are un-necessary. 13117 Fri Jul 14 17:47:03 2017 gautamUpdateGeneralDisks from LLO have arrived [jamie, gautam] Today morning, the disks from LLO arrived. Jamie and I have been trying to get things back up and running, but have not had much success today. Here is a summary of what we tried. Keith Thorne sent us two disks: one has the daqd code and the second is the boot disk for the FE machines. Since Jamie managed to successfully compile the daqd code on FB1 yesterday, we decided to try the following: mount the boot disk KT sent us (using a SATA/USB adapter) on /mnt on FB1, get the FEs booted up, and restart the RT models.  Quote: I just want to mention that the situation is actually much more dire than we originally thought. The diskless NFS root filesystem for all the front-ends was on that fb disk. If we can't recover it we'll have to rebuilt the front end OS as well. As of right now none of the front ends are accessible, since obviously their root filesystem has disappeared. While on FB1, Jamie realized he actually had a copy of the /diskless/root directory, which is the NFS filesystem for the FEs, on FB1. So we decided to try and boot some of the FEs with this (instead of starting from scratch with the disks KT sent us). The way things were set up, the FEs were querying the FB machine as the DHCP server. But today, we followed the instructions here to get the FEs to get their IP address from chiara instead. We also added the line /diskless/root *(sync,rw,no_root_squash,no_all_squash,no_subtree_check) to /etc/exports followed by exportfs -ra on FB1. At which point the FE machine we were testing (c1lsc) was able to boot up. However, it looks like the NFS filesystem isn't being mounted correctly, for reasons unknown. We commented out some of the rtcds related lines in /etc/rc.local because they were causing a whole bunch of errors at boot (the lines that were touched have been tagged with today's date). So in summary, the status as of now is: 1. Front-end machines are able to boot 2. There seems to be some problem during the boot process, leading to the NFS file system not being correctly mounted. The closest related thing I could find from an elog search is this entry, but I think we are facing a different probelm. 3. We wanted to see if we could start the realtime models (but without daqd for now), but we weren't even able to get that far today. We will resume recovery efforts on Monday. 1030 Tue Oct 7 10:49:29 2008 AlbertoUpdateGeneralDisplaced Photodiode This morning I found that the photodidode of the PLL in the PSL table was not aligned to the beam anymore. The PD support was not tight to the pedestal so that the PD was rotated and completely off of the beam. It is possible that the BNC cable connected to the PD was pulled very strongly, or the PD was hit so that the support got unscrewed by its pedestal. Anyways, it did not happen spontaneously. I re-aligned the PD and observed again the beat between the two laser beams. Here are the values from the measurement of the signal from the PD: I measured the DC values of the hitting power, alternatively occluding one of the two laser beams, and I measured the beat amplitude letting them interfere and reading the peak-to-peak amplitude of the oscillating signal: main beam DC: 200mV secondary beam DC: 490 beat: 990mV beat at the spectrum analyzer (after the two-way splitter of the PLL): -8.40dBm on a noise floor of the photodiode of -75dBm the frequency of the beast is 8.55MHz and the temperature of the NPRO of the secondary beam, as read from the laser driver display, is 48.7357C. Alberto 1845 Thu Aug 6 17:51:21 2009 ChrisUpdateGeneralDisplacement Sensor Update For the past week Dmass and I have been ordering parts and getting ready to construct our own modified version of EUCLID (figure). Changes to the EUCLID design could include the removal of the first lens, the replacement of the cat's eye retroreflector with a lens focusing the beam waist on a mirror in that arm of the Michelson, and the removal of the linear polarizers. A beam dump was added above the first polarizing beam splitter and the beam at Photodetector 2 was attenuated with an additional polarizing beam splitter and beam dump. Another proposed alteration is to change the non-polarizing beam splitter from 50/50 to 33/66. By changing the reflectivity to 66\%, less power coming into the non-polarizing beam splitter would be lost" at the reference detector (1/3 instead of 1/2), and on the return trip less power would be lost at the polarizing beam splitter (1/6 instead of 1/4). Also, here's a noise plot comparing a few displacement sensors that are used to the shot noise levels for the three designs I've been looking at. 1846 Thu Aug 6 18:21:03 2009 ChrisUpdateGeneralDisplacement Sensor Update  Quote: For the past week Dmass and I have been ordering parts and getting ready to construct our own modified version of EUCLID (figure). Changes to the EUCLID design could include the removal of the first lens, the replacement of the cat's eye retroreflector with a lens focusing the beam waist on a mirror in that arm of the Michelson, and the removal of the linear polarizers. A beam dump was added above the first polarizing beam splitter and the beam at Photodetector 2 was attenuated with an additional polarizing beam splitter and beam dump. Another proposed alteration is to change the non-polarizing beam splitter from 50/50 to 33/66. By changing the reflectivity to 66\%, less power coming into the non-polarizing beam splitter would be lost" at the reference detector (1/3 instead of 1/2), and on the return trip less power would be lost at the polarizing beam splitter (1/6 instead of 1/4). Also, here's a noise plot comparing a few displacement sensors that are used to the shot noise levels for the three designs I've been looking at. I thought slightly harder and I think that the beamsplitter stays. We will lose too much power on the first PD if we do that: 33/66: Pwr @ PD2 = 2/3*1/3*1/2 = 1/9 Pin Pwr @ PD3 = 2/3*2/3*1/2 = 2/9 Pin 50:50 Pwr @ PD2 = PWR @ PD3 = 1/8 Pin balancing them is probably better. 2407 Sun Dec 13 23:18:09 2009 ranaSummaryIOODisplacement noise on the PSL table For the Laser Gyro, I wondered how much mechanical noise we might get with a non-suspended cavity. My guess is that the PMC is better than we could do with a large ring and that the MZ is much worse than we could do. Below 5 Hz, I think the MZ is "wind noise" limited. Above 10 Hz, its just ADC noise in the readout of the PZT voltage. 13508 Sat Jan 6 05:18:12 2018 KevinUpdatePonderSqueezeDisplacement requirements for short-term squeezing I have been looking into whether we can observe squeezing on a short timescale. The simulations I show here say that we can get 2 dBvac of squeezing at about 120 Hz using extreme signal recycling. The parameters used here are • 100 ppm transmissivity on the folding mirrors giving a PRC gain of 40. • 10 kΩ series resistance for the ETMs; 15 kΩ series resistance for the ITMs. • 1 W incident on the back of PRM. • PD quantum efficiency 0.88. The first attachment shows the displacement noise. The red curve labeled vacuum is the standard unsqueezed vacuum noise which we need to beat. The second attachment shows the same noise budget as a ratio of the noise sources to the vacuum noise. This homodyne angle and SRC detuning give about the maximum amount of squeezing. However, there's quite a bit of flexibility and if there are other considerations, such as 100 Hz being too low, we should be able to optimize these angles (even with more pessimistic values of the above parameters) to see at least 0.2 dBvac around 400 Hz. 13509 Sat Jan 6 13:47:32 2018 ranaUpdatePonderSqueezeDisplacement requirements for short-term squeezing • ought to tune for 210 Hz (in-between powerlines) since 100 Hz is tough to work due to scattering, etc. • rename DAC - I think what this curve shows is really the coil driver noise. The DAC noise we can always filter out with the dewhitening board; i.e. once we have 1000x attenuation between the DAC and the coil driver input, DAC noise is not dominant. 13511 Sat Jan 6 23:25:18 2018 KevinUpdatePonderSqueezeDisplacement requirements for short-term squeezing  Quote: ought to tune for 210 Hz (in-between powerlines) since 100 Hz is tough to work due to scattering, etc. We can get 1.1 dBvac at 210 Hz. The first two attachments are the noise budgets for these optimized angles. The third attachment shows squeezing as a function of homodyne angle and SRC detuning at 210 Hz. To stay below -1 dBvac, the homodyne angle must be kept between 88.5 and 89.7 degrees and the SRC detuning must be kept between -0.04 and 0.03 degrees. This corresponds to fixing the SRC length to within a range of 0.07/360 * 1064 nm = 200 pm. 13512 Sun Jan 7 03:22:24 2018 KojiUpdatePonderSqueezeDisplacement requirements for short-term squeezing Interesting. My understanding is that this is close to signal recycling, rather than resonant sideband extraction. Is that correct? For signal recycling, we need to change the resonant condition of the carrier in the SRC. Thus the macroscopic SRC length needs to be changed from ~5.4m to 9.5m, 6.8m, or 4.1m. In the case of 6.8m, SRC legnth= PRC length. This means that we can use the PRM (T=5%) as the new SRM. Does this T(SRM)=5% change the squeezing level? 13513 Sun Jan 7 11:40:58 2018 KevinUpdatePonderSqueezeDisplacement requirements for short-term squeezing Yes, this SRC detuning is very close to extreme signal recycling (0° in this convention), and the homodyne angle is close to the amplitude quadrature (90° in this convention). For T(SRM) = 5% at the optimal angles (SRC detuning of -0.01° and homodyne angle of 89°), we can see 0.7 dBvac at 210 Hz. 13514 Sun Jan 7 17:27:13 2018 gautamUpdatePonderSqueezeDisplacement requirements for short-term squeezing Maybe you've accounted for this already in the Optickle simulations - but in Finesse (software), the "tuning" corresponds to the microscopic (i.e. at the nm level) position of the optics, whereas the macroscopic lengths, which determine which fields are resonant inside the various cavities, are set separately. So it is possible to change the microscopic tuning of the SRC, which need not necessarily mean that the correct resonance conditions are satisfied. If you are using the Finesse model of the 40m I gave you as a basis for your Optickle model, then the macroscopic length of the SRC in that was ~5.38m. In this configuration, the f2 (i.e. 55MHz sideband) field is resonant inside the SRC while the f1 and carrier fields are not. If we decide to change the macroscopic length of the SRC, there may also be a small change to the requirements on the RoCs of the RC folding mirrors. Actually, come to think of it, the difference in macroscopic cavity lengths explains the slight differences in mode-matching efficiencies I was seeing between the arms and RCs I was seeing before.  Quote: Yes, this SRC detuning is very close to extreme signal recycling (0° in this convention), and the homodyne angle is close to the amplitude quadrature (90° in this convention). For T(SRM) = 5% at the optimal angles (SRC detuning of -0.01° and homodyne angle of 89°), we can see 0.7 dBvac at 210 Hz. 13515 Sun Jan 7 20:11:54 2018 KojiUpdatePonderSqueezeDisplacement requirements for short-term squeezing In fact, that is my point. If we use signal recycling instead of resonant sideband extraction, the "tuning" of the SRC is opposite to the current setup. We need to change the macro length of the SRC to make 55MHz resonant with this tuning. And if we make the SRC macro length together with the PRC macro length for this reason, we need to thing again about the mode matching. Fortunately, we have the spare PRM (T=5%) which matches with this curvature. This was the motivation of my question. We may also choose to keep the current SRM because of its higher T and may want to evaluate the effect of expected mode mismatch. 256 Wed Jan 23 12:31:36 2008 AndreySummarySUSDissapointing Results of XARM optimization (PDF-file) I attach a PDF-file which summarizes briefly the results of measurements/calculations of Q-factors for ITMX mass as a function of suspension damping gain, and this file contains the results of measurements of RMS peaks on the values of suspension gains of ITMX and ETMX (see ELOG entries from December 2007, specifically #202, #199, #194)), but now those dependences are plotted in Q-ITMX and Q_ETMX axes. Unfortunately, there are no clear narrow areas of minimum in those dependences (that explains the sad title of this ELOG entry). The attached pdf-file can be shown as a short presentation for a wall during our Wednesday meeting. 8559 Thu May 9 15:07:51 2013 JenneUpdateGeneralDistances from CAD drawing Since I keep asking Manasa to "measure" distances off of the CAD drawing for me, I thought I might just write them all down, and quit asking. So, these are only valid until our next vent, but they're what we have right now. All distances are in meters, angles in degrees. 4696 Wed May 11 23:02:52 2011 valeraUpdateASSDither angular stabilizitaion system update This is what was done in past two days: - The ETMY and ITMY pitch and yaw dofs are modulated at 40, 44, 42, 46 Hz respectively (oscillator A=30). The c1ass lockin numbers are 12, 14, 27, 29. - The NAS55I signal is demodulated at the above frequencies. The demodulated I/Q signal phase is set to shift all signal into I-phase. The lockin inputs are bandpassed around respective frequency f with butter("Bandpass",2,f-0.5,f+0.5). The demod signals are then additionally low passed with butter ("Lowpass",4,0.5) so the servo ugf has to be below 0.5 Hz. The servo filter is p:z 0.0001:0.1. - The ETMY demodulated signal is fed back to ITMY and visa versa. - With the above 2x2 servo running we moved the input beam PZTs by hand to follow the cavity. - At the end we offloaded the servo control signals to the SUS biases again by hand. - The beam spot centering was estimated by unbalancing the ETMY/ITMY pitch/yaw coil combinations intentionally by 5%, which produces 1.3 mm shift of the node, and comparing the response to the residual signals. - The dof set up currently is: ETMY pitch lockin 12 -> dof2, ITMY pitch lockin 14 -> dof4, ETMY yaw lockin 27 -> dof7, ITMY yaw lockin 29 -> dof9 - The next step is to demodulate the TRY(X) and servo the input beam PZTs 5165 Wed Aug 10 02:40:40 2011 JennyUpdatePSLDither freq for PZT chosen: 2.418 MHz I've finished using the network analyzer to characterize find a dither frequency for driving the PZT to use in my PDH locking. I found a region in which the amplitude response of the PZT is low: The dip is centered at 2.418 MHz. Changing the NPRO laser temperature by 100mK has no significant effect on the transfer function in that region. I will post plots tomorrow. I'm finished with the network analyzer. It is unplugged, and the cart is still near the PSL table. (I'll roll it back tomorrow when it won't disturb interferometer locking). I closed the shutter on the NPRO at the end of the night. Tomorrow I plan to put together the fast locking setup. I'll drive the PZT at 2.418 MHz. More details to come tomorrow. 10581 Wed Oct 8 03:20:46 2014 JenneUpdateLSCDo we need AO for acquisition? As part of trying to determine whether we require the AO path for lock acquisition, or if we can survive on just digital loops, I looked at the noise suppression that we can get with a digital loop. I took a spectrum of POX, and calibrated it using a line driving ETMX to match the ALSX_FINE_PHASE_OUT_HZ channel, and then I converted green Hz to meters. I then undid the LSC loop that was engaged at the time (XARM FMs 1,2,3,4,5,8 and the pendulum plant), to infer the free running arm motion. I also applied the ALS filters (CARM FMs 1,2,3,5,6) and the pendulum plant to the free running noise to infer what we expect we could do with the current digital CARM filters assuming we were not sensor noise limited. In the figure, we see that the free running arm displacement is inferred to be about 0.4 micrometers RMS. The in-loop POX signal is 0.4 picometers RMS, which (although it's in-loop, so we're not really that quiet) is already better than 1/10th the coupled cavity linewidth. Also, the CARM filters that we use for the ALS lock, and also the sqrtInvTrans lock are able to get us down to about 1 pm RMS, although that is not including sensor noise issues. For reference, here are the open loop gains for the LSC filters+pendulum and ALS filters+pendulum that we're currently using. The overall gain of these loops have been set so the UGF is 150Hz. It seems to me that as long as our sensors are good enough, we should be able to keep the arm motion down to less than 1/10th or 1/20th the coupled cavity linewidth with only the digital system. So, we should think about working on that rather than focusing on engaging the AO path for a while. 1272 Wed Feb 4 19:22:57 2009 YoichiUpdateGeneralDo we need off-axis parabolic mirrors ? I also estimated the mode matching degradation caused by the astigmatism. Since the incident angles to the mode matching mirrors are not 0, the effective focal lengths in the incident plane and the perpendicular plane are different. This effect leads to astigmatism of the beam. When there is astigmatism, the maximum achievable mode matching rate becomes less than 100%. According to my calculation, the mode matching cannot be better than 94% for the input beam. For the output mode matching, we can theoretically achieve more than 99% even with the astigmatism. The difference comes from the fact that the OMMT is longer, thus the incident angle is smaller. If we don't like this 94%, we have to use off-axis parabolic mirrors, or modify the IMMT to a longer one. I prefer to make it longer. Just 5" elongation will increase the mode matching rate to 99.4%. We have a room for this 5" elongation. Again, the details of the calculation are added to the Mathematica notebook below.  Quote: I did mode matching calculations for the new optical layout. For the input mode matching, we have to change the focal length of the second mirror from 687mm to 315mm and the distance between the two MMT mirrors from 137mm to 149.2mm. For the mode matching to the OMC, we only have to change the distance between the OMMT mirrors from 384mm to 391mm. No need to change the mirrors. Details of the calculations can be found in http://lhocds.ligo-wa.caltech.edu:8000/40m/Upgrade_08/Optical_Layout?action=AttachFile&do=get&target=NewRecyclingCavities.zip (Mathematica notebook) or if you prefer PDF, here http://lhocds.ligo-wa.caltech.edu:8000/40m/Upgrade_08/Optical_Layout?action=AttachFile&do=get&target=NewRecCav.pdf 1274 Thu Feb 5 10:42:33 2009 YoichiUpdateGeneralDo we need off-axis parabolic mirrors ? No way ! I made a mistake in estimating the astigmatism problem. If we use the current MMT1 as it is, this one is already an off-axis parabolic (OAP) mirror. In this case, the astigmatism of this mirror is very small (if we use it with the correct angle). I did not include this effect in the previous calculation. It turned out that the maximum achievable mode matching becomes far smaller (only 77%) if we use the OAP for MMT1 and a spherical mirror for MMT2. This is not acceptable. The reason behind this is that when we use spherical mirrors for both MMT mirrors, the astigmatism caused by the MMT1 is somewhat canceled by the astigmatism of MMT2. We don't get this cancellation if we mix OAP and spherical mirrors. We should either (1) change MMT1 to a spherical mirror and keep the length of the input MMT as it is, or (2) change MMT1 to a spherical mirror and elongate the length of the input MMT. In the case of (1) the maximum achievable mode matching is 94%. The focal length of MMT2 should be 315.6mm. If we do (2), the mode matching rate can be as high as 99.8%. The focal lengths are MMT1 = -301.3mm, MMT2=558mm. The distance between the mirrors is 262mm. We have enough space to do this elongation. But we have to mechanically modify the MMT mount. I prefer (2). As usual, the document on the Wiki was updated to include the above calculations. 11113 Sat Mar 7 18:53:48 2015 JenneUpdateLSCDoF selector matrices replaced with filter banks This is work that I did yesterday but didn't have time to elog. Since it seems non-trivial to give ourselves ramping matrices, but we only really needed the ramping in the DoF selector matrices, I've replaced the separate _A and _B parts with full filterbanks. Recall from elog 10910 that I had given each degree of freedom's _A and _B input options an offset, an epics monitor and a test point. Now those are removed, and handled inside of the filter banks. The outputs of the filter banks sum together. This required some screen modifications, but everything should work the same way that it did before this change. I've also changed the DAQ channels from the _A_ERR and _B_ERRs that I had hand-created to now be the _A_OUT and _B_OUT test points from the filter banks (acquired at 2048Hz). I have not yet modified the burt snapshots for the ifo configure screen. The arms will work the same as always, since they didn't have any selector matrix stuff ever, but the rest still need tweaking. 16249 Fri Jul 16 16:26:50 2021 gautamUpdateComputersDocker installed on nodus I wanted to try hosting some docker images on a "private" server, so I installed Docker on nodus following the instructions here. The install seems to have succeeded, and as far as I can tell, none of the functionality of nodus has been disturbed (I can ssh in, access shared drive, elog seems to work fine etc). But if you find a problem, maybe this action is responsible. Note that nodus is running Scientific Linux 7.3 (Nitrogen). 13858 Thu May 17 13:51:35 2018 Jon RichardsonConfigurationElectronicsDocumentation & Schematics for AUX-PSL PLL [Jon, Gautam] Attached is supporting documentation for the AUX-PSL PLL electronics installed in the lower PSL shelf, as referenced in #13845. Some initial loop measurements by Gautam and Koji (#13848) compare the performance of the LB1005 vs. an SR560 as the controller, and find the LB1005 to be advantageous (a higher UGF and phase margin). I have some additional measurements which I'll post separately. Loop Design Pickoffs of the AUX and PSL beams are routed onto a broadband-sensitive New Focus 1811 PD. The AUX laser temperature is tuned to place the optical beat note of the two fields near 50 MHz. The RF beat note is sensed by the AC-coupled PD channel, amplified, and mixed-down with a 50 MHz RF source to obtain a DC error signal. The down-converted term is isolated via a 1.9-MHz low-pass filter in parallel with a 50 Ohm resistor and fed into a Newport LB1005 proportional-integral (PI) servo controller. Controller settings are documented in the below schematic. The resulting control signal is fed back into the fast PZT actuator input of the AUX laser. Hardware Photos 13876 Tue May 22 10:14:39 2018 Jon RichardsonConfigurationElectronicsDocumentation & Schematics for AUX-PSL PLL Quote: [Jon, Gautam] Attached is supporting documentation for the AUX-PSL PLL electronics installed in the lower PSL shelf, as referenced in #13845. Some initial loop measurements by Gautam and Koji (#13848) compare the performance of the LB1005 vs. an SR560 as the controller, and find the LB1005 to be advantageous (a higher UGF and phase margin). I have some additional measurements which I'll post separately. Loop Design Pickoffs of the AUX and PSL beams are routed onto a broadband-sensitive New Focus 1811 PD. The AUX laser temperature is tuned to place the optical beat note of the two fields near 50 MHz. The RF beat note is sensed by the AC-coupled PD channel, amplified, and mixed-down with a 50 MHz RF source to obtain a DC error signal. The down-converted term is isolated via a 1.9-MHz low-pass filter in parallel with a 50 Ohm resistor and fed into a Newport LB1005 proportional-integral (PI) servo controller. Controller settings are documented in the below schematic. The resulting control signal is fed back into the fast PZT actuator input of the AUX laser. Hardware Photos 11823 Mon Nov 30 10:41:45 2015 yutaroUpdateLSCDoes a baffle in front of ETMY have effect on loss map measurement? It might have, so I think I need to estimate shift of beam spot more preciely. According to Steve's drawing, radius of the hole of the baffle is 19.8 mm. Intensity distribution of fundamental mode in x axis direction is this (y is integrated out): $I(x)=\frac{1}{\sqrt{2\pi(w/2)^2}}e^{-\frac{1}{2}\left(\frac{x}{w/2}\right)^2}$ With the radius of curvature of ETMY of 60 m and the arm length of 37.78 m, the beam width $w$ on ETMY is estimated to be 5.14 mm. From this expression of the intensity, $\int^\infty_{x=9.56\mathrm{mm}}\mathrm{d}xI(x)=100\,\mathrm{ppm},\,\int^\infty_{x=10.00\mathrm{mm}}\mathrm{d}xI(x)=50\,\mathrm{ppm}$, for example. If round trip loss is considered, these values are doubled. Although maximum shift of beam spot from the ideal spot on ETMY is estimated to be sqrt(6.0^2+(1.7+1.7)^2)=6.9 mm, this value could have error of several tens of % because I am not sure to what exten the calibration is precise, which means that the maximum shift could be ~10 mm and seperation between the baffle and the beam could be ~10 mm. Therefore, I need to check how much the beam spot shifts with another way, maybe with captured image of the CCD camera. 11828 Mon Nov 30 17:17:30 2015 yutaroUpdateLSCDoes a baffle in front of ETMY have effect on loss map measurement? With captured images of ETMYF, I measured the shift of the beam spot on ETMY. The conclusions are: the baffle would have almost no effect on loss map measurement and the calibration of beam spot shift is confirmed to be not so bad. What I did: I captured ETMYF images in the cases that (i)beam spot is centered on ETMY, beam spot is at the rightest and lowest point of my loss map measurement (corresponding to [0,0] component of the matrix shown in elog 11818), and beam spot is at the leftest and highest point of my loss map measurement ([4,4] component). Each captured image is attached. Then using ImageJ, I measured the shift of the beam spot. I calibrated lengh in horizontal direction and vertical direction with the diameter of the mirror. Results: The amount of the beam shift was 7.2 mm and 8.0 mm for each case. These values indicate that clapping loss due to the baffle is less than 10 ppm in a round trip. Today's results support the previous calibration with oplev, which says the amount of the beam shift is 7.0 mm. Two values derived by different calibrations coincide within ~10 % though they are totally different methods. This also support the calibration of the oplev for ETMY (elog 11785) indirectly. 7321 Thu Aug 30 19:08:08 2012 JenneUpdateVACDogs on BS, ITM chambers checked I tightened as many of the dog clamps on the bottom of the BS, ITMX and ITMY chambers as I could find. I used a torque wrench at 45 ft-lbs. Some of the bolts of the dogs were too long, and I couldn't find an extender thing to accommodate the bolt so I could reach the nut. None of the bolts moved that I was able to reach. Steve, we're not doing final final alignment today (we will do it tomorrow), so please go around and double-check my work by checking all of the dogs first thing in the morning. Thanks. 14487 Wed Mar 20 12:31:30 2019 JonUpdateVACDoing vac controls work I'm rebooting the IOLAN server to load new serial ports. The interlocks might trip when the pressure gauge readbacks cut out. 14489 Wed Mar 20 20:07:22 2019 JonUpdateVACDoing vac controls work Work is completed and the vac system is back in its nominal state.  Quote: I'm rebooting the IOLAN server to load new serial ports. The interlocks might trip when the pressure gauge readbacks cut out. 10029 Wed Jun 11 20:09:37 2014 ZachConfigurationWikiDokuWiki situation I have been looking into the DokuWiki situation, with no great progress so far. The problem is with authentication. When you try to access the wiki, you get: "User authentication is temporarily unavailable. If this situation persists, please inform your Wiki Admin." As Evan points out, this goes away if you turn off ACL (Access Control Lists), but---as he also mentions---that just means that authentication is disabled, so the wiki becomes open. All signs point to this being a problem with the authentication mechanism. We use the 'authplain' plaintext method, where the usernames and hashed passwords are stored in a plaintext file. Evan and I have both done plenty of testing with the config settings to see if the problem goes away. Even if you restore everything to default (but enable ACL using authplain and the existing user file), you still get an error. I went as far as installing a brand new wiki on the web server, and, surprisingly, this also exhibits the problem. Interestingly, if I install an old enough version (2012-10-13), it works fine. After this revision, they transitioned their authentication methods from "backends" to "plugins", so this is a clue. As a side note, the other wikis on nodus (ATF and Cryo) are running earlier versions of DokuWiki, so they have no problems. As it stood, our options were: 1. No wiki (not even read-only, since the issue prevents logging in and also prevents anonymous reading, somehow) 2. No ACL = open wiki. Also not good. So, I created a temporary read-only version of the wiki using the aforementioned earlier DokuWiki release. It has a soft link to the real wiki data, but I deleted the user database so no one can log in and edit (I also disabled registration). It can be found at https://nodus.ligo.caltech.edu:30889/wiki_ro/. I also created a backup of the real wiki as wiki_bak to avoid any potential disasters. The simplest thing to do would be to just roll the wiki back to this working version, but that doesn't sound so smart. Clearly, it was working with the plugin structure before our snafu, and somehow our fixing everything else has broken it. Quote:  Quote: It looks like auth is broken on the AIC wiki (though working fine on ATF and Cryo). I did some poking around but can't see how anything we did could have broken it. I went into local.php and changedconf['useacl'] = 1; to $conf['useacl'] = 0; and it looks like the auth issue goes away (I've changed it back). This isn't a fix (we want to use access control), but it gives us a clue as to where the problem is. 10021 Tue Jun 10 19:11:27 2014 EvanConfigurationWikiDokuWikis are back up As of this writing, the DokuWiki appears to be working. As you and I suspected, it looks like this was a clusterwhoops with the permissions for the NFS mount. Let's recap what happened in the past 24 hours: 1. Yesterday, 8 PM: I restart the Apache server, thereby resurrecting the SVN (now conveniently located at /export/home/svn). The DokuWikis remain borked. 2. Yesterday, 7 to 11 PM: Zach, Rana, and Jenne perform deep magic to get the front-end machines up and running again. This should be irrelevant for this Apache/SVN/DokuWiki witchcraft. 3. Today, morning: the townsfolk happily resume their svn up and svn ci festival. 4. Today, ca. 3 PM: Zach runs stopapache.sh to bring down Apache, thinking he can bring it back up momentarily with startapache.sh. But NFS is a jealous and vengeful god, and Apache now complains that it doesn't have permission to write to its logfiles, and therefore can't start httpd. 5. Today, 5 PM: "How can this be?", Zach and I ask. Apache had no problem starting up yesterday night, and to our knowledge nobody futzed with chiara's NFS mount of /home/cds. This change remains mysterious to us. Despite the aforementioned mystery, Zach and I pressed on and tried to diagnose the permissions issue. We found that even if you are logged into nodus or pianosa or rossa or whatever as the controls user, the NFS mount saw us as the user nobody (in the group nogroup). If we created a file on the NFS mount, it was owned by nobody/nogroup. If we tried to modify a file on the NFS mount that was owned by controls/controls or controls/staff, we got a "permission denied" error, even if we tried with superuser privileges. It turns out this has to do with the vagaries of NFS (scroll down to gotcha #4). We have all_squash enabled in /etc/exports , which means that no matter your username or group on nodus, rossa, pianosa, or harpischordsa, NFS coerces your UID/GID to chiara's nobody/nogroup. Anyway, the fix was to go into chiara's /etc/exports and change this /home/cds 192.168.113.0/255.255.255.0(rw,sync,no_subtree_check,all_squash,insecure) to this /home/cds 192.168.113.0/255.255.255.0(rw,sync,no_subtree_check,all_squash,anonuid=1001,anongid=1001,insecure) where 1001/1001 are the UID/GID for chiara's controls/controls (as opposed to 65534/65534 for chiara's nobody/nogroup). That way, the NFS mount sees you as chiara's controls/controls. In order to make chiara's NFS daemon aware of the new /etc/export settings, I ran sudo exportfs -r based on the answer to this StackOverflow question. As with all the best StackOverflow questions, the moderators closed it for being "off-topic". [Edit, 2014-06-11, 11 AM: I've repeated the above anonuid/anongid change for the /home/cds/caltech/home/controls mount, so that nodus's /home/controls is writeable as well. I've also added a .screenrc for nodus in order to maintain sanity.] 10022 Wed Jun 11 05:16:14 2014 ZachConfigurationWikiDokuWikis are back up It looks like auth is broken on the AIC wiki (though working fine on ATF and Cryo). I did some poking around but can't see how anything we did could have broken it.  Quote: As of this writing, the DokuWiki appears to be working. 10024 Wed Jun 11 10:15:15 2014 EvanConfigurationWikiDokuWikis are back up Quote: It looks like auth is broken on the AIC wiki (though working fine on ATF and Cryo). I did some poking around but can't see how anything we did could have broken it.  Quote: As of this writing, the DokuWiki appears to be working. I went into local.php and changed$conf['useacl'] = 1; to $conf['useacl'] = 0; and it looks like the auth issue goes away (I've changed it back). This isn't a fix (we want to use access control), but it gives us a clue as to where the problem is. 10366 Mon Aug 11 23:50:38 2014 ranaConfigurationWikiDokuWikis are back up Quote:  Quote: It looks like auth is broken on the AIC wiki (though working fine on ATF and Cryo). I did some poking around but can't see how anything we did could have broken it. I went into local.php and changed$conf['useacl'] = 1; to \$conf['useacl'] = 0; and it looks like the auth issue goes away (I've changed it back). This isn't a fix (we want to use access control), but it gives us a clue as to where the problem is.

There was still some residual permissions issue. This is now bypassed and so the ACL is ON and all seems to be back the way it was. I've tested that I can login and edit the wiki.

Some useless knowledge follows here. Please ignore.

After some hours of reading unhelpful DokuWiki blogs, I just put the backup wiki into the local disk on NODUS and then made a soft link to point to that from /users/public_html/wiki/. So this implies that the new NFS setup on chiara is different enough that it doesn't allow read/write access to the apache user on the NODUS/Solaris machine.

12935   Mon Apr 10 15:22:46 2017 ranaConfigurationWikiDokuWikis are back up

AIC Wiki updated to latest stable version of DokuWiki: 2017-02-19b "Frusterick Manners" + CAPTCHA + Upgrade + Gallery PlugIns

10019   Tue Jun 10 11:54:36 2014 ZachConfigurationWikiDokuWikis are still down

Not sure if someone is already on this, but the nodus DokuWikis are still down (AIC, ATF, Cryo, etc.)

I get:

DokuWiki Setup Error

The datadir ('pages') does not exist, isn't accessible or writable. You should check your config and permission settings. Or maybe you want to run the installer

4809   Mon Jun 13 15:33:55 2011 Jamie, JoeUpdateCDSDolphin fiber between 1Y3 and 1X4 appears to be dead

The fiber that connects the Dolphin card in the c1lsc machine (in the 1Y3 rack) to the Dolphin switch in the 1X4 rack appears to have died spontaneously this morning.  This was indicated by loss of Dolphin communication between c1lsc and c1sus.

We definitively tracked it down to the fiber by moving the c1lsc machine over to 1X4 and testing the connection with a short cable.  This worked fine.  Moving it back to using the fiber again failed.

Unfortunately, we have no replaced Dolphin fiber.  As a work around, we are stealing  a long computer->IO chassis cable from Downs and moving the c1lsc machine to 1X4.

This is will be a permanent reconfiguration.  The original plan was to have the c1lsc machine also live in 1X4.  The new setup will put the computer farther from the RF electronics, and more closely mimic the configuration at the sites, both of which are good things.

4815   Tue Jun 14 09:25:17 2011 JamieUpdateCDSDolphin fiber tested with c1sus, still bad

The bad Dolphin was still bad when tested with a connection between c1sus and the Dolphin swtich.

I'm headed over to Downs to see if we can resolve the issue with the PCIe extension fiber.

4045   Mon Dec 13 11:56:32 2010 josephb, alexUpdateCDSDolphin is working

Problem:

The dolphin RFM was not sending data between c1lsc and c1sus.

Solution:

Dig into the controller.c code located in /opt/rtcds/caltech/c1/core/advLigoRTS/src/fe/.  Find this bit of code on line 2173:

2173 #ifdef DOLPHIN_TEST 2174 #ifdef X1X14_CODE 2175         static const target_node = 8; //DIS_TARGET_NODE; 2176 #else 2177         static const target_node = 12; //DIS_TARGET_NODE; 2178 #endif 2179         status = init_dolphin(target_node);

Replace it with this bit of code:

2173 #ifdef DOLPHIN_TEST 2174 #ifdef C1X02_CODE 2175         static const target_node = 8; //DIS_TARGET_NODE; 2176 #else 2177         static const target_node = 4; //DIS_TARGET_NODE; 2178 #endif 2179         status = init_dolphin(target_node);

Basically this was hard coded for use at the site on their test stands.  When starting up, the dolphin adapter would look for a target node to talk to, that could not be itself.  So, all the dolphin adapters would normally try to talk to target_node 12, unless it was the X1X14 front end code, which happened to be the one with dolphin node id 12.  It would try to talk to node 8.

Unfortunately, in our setup, we only had nodes 4 and 8.  Thus, both our codes would try to talk to a nonexistent node 12.  This new code has everyone talk to node 4, except the c1x02 process which talks to node 8 (since it is node 4 and can't talk to itself).

I'm told this stuff is going away in the next revision and shouldn't have this hard coded stuff.

Different Dolphin Problem and Fix:

Apparently, the only models which should have pciRfm=1 are the IOP models which have a dolphin connection.  Front end models that are not IOP models (like c1lsc and c1rfm) should not have this flag set.  Otherwise they include the dolphin drivers and causes them and the IOP to refuse to unload when using rmmod.

So pciRfm=1 only in IOP models using Dolphin, everyone else should not have it or should have pciRfm=-1.

Current CDS status:

 MC damp dataviewer diaggui AWG c1ioo c1sus c1iscex RFM Dolphin RFM Sim.Plant Frame builder TDS
ELOG V3.1.3-