40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 297 of 344  Not logged in ELOG logo
ID Date Authorup Type Category Subject
  10380   Wed Aug 13 23:08:17 2014 ranaUpdateIOOFSS box TFs

As EQ pointed out recently, we're injecting into the FSS error point just after an RF pi filter, but before the VGA. We wondered what the weird filter impedance was doing to our signal if we inject after it. I used LISO to model this FSS common section and attach the plots.

The first plot shows the TF between the Test 1 input and the AD602 VGA input. This is NOT the input that we are actually using.

The second plot shows the TF between the IN1 port (which we are actually using) and the VGA input.

Neither of them shows the 1 MHz bump that we see in the measurements, so I suspect that the board has been modified...the hunt continues. We've got to pop the top of the TTFSS and take photos and measure from IN1 to VGA input.

** FSScomm.fil is now in the LISO SVN. The following command line will run it with two different cases and cat the PDF files into one. If you use an auto-refresh PDF viewer like Okular or Mac Preview, its a nicer display than the usual GNUplot window:

./mfil FSScomm.fil; sleep 1; pdftk FSScomm_run*.pdf cat output FSScomm.pdf

  10381   Wed Aug 13 23:58:49 2014 ranaHowToComputer Scripts / ProgramsHP8591E spectrum analyzer remote scan

Quote:

The script for running continuous scans on HP 8591E spectrum analyzer is located at scripts/general/netgpibdata/HP8591E_contdScan.py

There was no such script in the directory when I looked today, but I found one called HP8591E. Of course, it didn't run because it hadn't been tested from the scripts directory and pointed to some /users/nichin/ stuff.

I modified a couple of lines and then committed it and the default .YML parameter file to the SVN. It runs and produces plots continuously from the scripts directory.

*** also, as you can see, we have mostly recovered the green beat amplitudes after yesterday's FLL attack on the ALS ***

  10391   Thu Aug 14 19:23:25 2014 ranaHowToIOOHow do I set the FSS offset to make the PZT voltage start at the right place?

 When the IMC locks, we want the FAST OUT of the TTFSS box to be close to zero volts. We also want the control signal from the MC Servo board to be close to 0 V. How to set this up?

With the IMC locked, we just servo the FSS input offset to minimize the MC board output :

ezcaservo -r C1:IOO-MC_FAST_MON -g 0.1 -t 10 C1:PSL-FSS_INOFFSET

I would have used "CDSUTILS", but that seems to have some sort of ridiculous bug where we can't have prefixes on channel names, even on the command line. 

  10393   Thu Aug 14 20:52:36 2014 ranaUpdateWikiViolin Mode table added to Wiki

Mech Resonance Wiki

I've updated the wiki by trawling the elog for violin entries. Please keep it up to date so that we can make violin notches.

 

  10397   Thu Aug 14 23:19:49 2014 ranaSummaryLSCETM Violin fundamental filters moved to LSC

 We used to do violin mode and test mass body mode notches in the SUS-LSC filter modules. Now we want them balanced in the LSC and triggered by the LSC, so they're in the filter modules which go from the the LSC output matrix to the SUS.

01.png

Today, we were getting ETM violin mode ringups while doing ALS hunt and so we moved the bandstops into the LSC. I also changed the bandstop from a wide one which missed the ETMX mode to a double bandstop which gets both the ETMX and the ETMY mode. See attached image of the Bode mag.

03.png

  10421   Thu Aug 21 22:10:52 2014 ranaSummaryComputer Scripts / Programsnetwork movements

 To help development of the data visualization project, we've assigned the .101 and .102 IP to DataVis. This is being used by the iMac in the control room via port 8 of the CDS switch near the Blue Plataeu Tournant.

We tried using one of the free ports, but Jamie realized that we had to use one of the already assigned ones due to some 'Smart' switch management software. So for the moment, please leave the iMac alone so that Bill can use it.

  10438   Fri Aug 29 17:28:07 2014 ranaUpdateGreen LockinguPDH Box Checkup

 

 I've been having trouble locking the X - green for the past few hours. Has there been some configuration change down there that anyone knows about?

I'm thinking that perhaps I need to replace the SHG crystal or perhaps remove the PZT alignment mirrors perhaps. Another possibility is that the NPRO down there is going bad. I'll start swapping the Y-end NPRO for the X-end one and see if that makes things better.

  10443   Wed Sep 3 00:17:22 2014 ranaUpdateGreen LockinguPDH Box Checkup

What monitor point is being plotted here? Or is it a scope probe output?

If this saturation is in the uPDH-X but not in the uPDH-Y, then just replace the VGA chip. Because these things have fixed attenuation inside, they often can't go the rails even when the chip is new.

In any case, we need to make a fix to get this box on the air in a fixed state before tomorrow evening.

Quote:

I had noticed in the past, that the digital control signal monitor for the X end would saturate well before the ADC should saturate (C1:ALS-X_SLOW_SERVO_IN1, which is from the "output mon" BNC on the box). It turns out that there is some odd saturation happening inside the box itself.

In this scope trace, the servo input is being driven with a 0.02Vpp, 0.1Hz sine wave, gain knob at 1.0. This is bad. 

TEK00006.PNG

Evan and I poked around the board, and discover that for some reason currently unknown to us, the variable gain amplifier (AD8336) can't reach its negative rail, despite the +-12V arriving safely at its power supply pins. 

I also realized that the LF356 in the integrator stage in this box had been replaced with a LT1792 by Kiwamu in ELOG 4373. I've updated my schematic, and will upload both boxes' schematics to the DCC page Jenne created for them. (D1400293 and D1400294)

 

  10445   Wed Sep 3 14:07:18 2014 ranaConfigurationGeneralnetgpibdata is working again now

Quote:

I gave the IPs to the bridges. According lines of /etc/hosts in linux1 were updated.

192.168.113.230 WET54G1
192.168.113.231 WET54G2

 I was going through some old Koji elogs to check them for correctness (as I do weekly). I noticed that back in Dec 2013, he made the above illegal modification of IP numbers. 192.168.113.230 was actually the IP for farfalla. Maybe that's why they were conflicting and farfalla not working and Q observing/imagining wireless GPIB dropouts?

I used the Wiki instructions to update the 2 bind9 files with a new number for farfalla (192.168.113.212) which was previously the number for the long dead op240m. Farfalla is restarted and sort of working. 

  10455   Fri Sep 5 00:56:00 2014 ranaSummaryOptical LeversITM OLs recentered: violations found

I re-centered the ITMX & ITMY Optical lever beams today since they were off. First I aligned the beam into the vacuum so that it went through the center of the on table optics and then tweaked the receiver optics alignment.

There are several bad practices on these which probably makes them drift:

  • plastic bases on some lens mounts
  • some lens mounts are fastened with a single dog instead of two
  • there is no need to use dogs on mounts that have screw holes. Just put the mount so that 2 screws with washers can be used. The placement for these is not so critical.
  • Use less steering mirrors! The ITMY OL path has 5 optics the beam enters the vacuum!!!

According to the datasheets, the laser has a beam diameter of 0.6 mm and a divergence angle of 1.3/2 mrad. So we can just calculate the right lens positions next time and not have to experiment with the whole visible laser lens kit.

For next Wednesday's cleanup, someone should volunteer to make the mounts more stable for the ITMs.

  10456   Fri Sep 5 03:36:00 2014 ranaUpdateComputer Scripts / Programsmartian wireless tweak

 I changed the Martian wireless router to use channel 10 instead of something random (as it was). Using the Android app 'Wifi Analyzer' we could see that the usual channels are dominated by FlumeLab and Caltech Beaver.

The range from 9-13 looked clean so we put it up there. Also, the signal strength drops from -45 to -70 dBm as we walk from the BS down to the ends. We need to tweak the router position and orientation to give us another 10 dB so that we can reliably run the laptops at the ends.

  10463   Sat Sep 6 01:48:54 2014 ranaUpdateGreen Lockingnew X Green PDH measurements

Quote:

Does this matter? Is there something in my simulation that I can correct that would give a more accurate calibration? 

Data, plots, code, attached. 

 What modulation depth are you using for the simulation? I have never seen a real measurement of that in our elog for the end-PDH systems.

I also disbelieve your RMS calculations. It looks like in the 1.5-0.5 Hz band we're picking up 50 kHz of frequency noise even though the 1 Hz peak is only 80 Hz/rHz, even though math says  "80 * sqrt(1) = 80".

Take a look at:

http://www.mathwords.com/r/root_mean_square.htm

and

http://www.ligo.caltech.edu/~rana/mat/utilities/rms.m

  10465   Sun Sep 7 17:06:38 2014 ranaUpdateGreen Lockingnew X Green PDH measurements

600 Hz seems ~OK. From the measured reflectivities for 532 nm, the green Finesse = 108. So the green cavity pole should be 18.3 kHz given an arm length of 37.8 m. 

600 Hz of green frequency noise means that we would get 38 pm RMS of arm mirror motion. We should assumed a peak/RMS factor of 10, so this would allow us to get to ~0.4 nm CARM offset.

However, its better than that. What we really care about for ALS is the amount of this green frequency noise which is put onto the arm. With an ALS feedback bandwidth of 100 Hz, my eyeball estimate say that the contribution from green PDH error will be ~100 Hz RMS, since we don't care too much about the 10 kHz stuff. So this seems good enough for now; let's figure out what's up with PDH-Y and get back to locking.

  10469   Mon Sep 8 11:34:47 2014 ranaUpdateComputer Scripts / Programspreparing vac system to reboot

FYI: in that rack, the +15V pulls ~0.5 A more than -15V usually. I think this is due to some RF amplifiers which are powered by this (e.g. the AOM that Manasa set up). The Sorensen's can source ~30A in principle, so we should make sure to set the current limit appropriately so as to not overheat them when there is a short.

Was this power supply not fused for all of its connections? I remember that this was connected to at least one un-fused connection in the past year.

  10483   Wed Sep 10 02:35:55 2014 ranaUpdateCDSOTTAVIA lost network connection

Quote:

Today the network connection of OTTAVIA was sporadic.

Then in the evening OTTAVIA lost completely it. I tried jiggle the cables to recover it, but in vain.

We wonder if the network card (on-board one) has an issue.

 I would also suspect IP conflicts; I had temporarily put the iMac on the Ottavia IP wire a few weeks ago. Hopefully its not back on there.

  10507   Mon Sep 15 18:55:51 2014 ranaUpdateDAQ40m frames onto the cluster

 Dan Kozak is rsync transferring /frames from NODUS over to the LDAS grid. He's doing this without a BW limit, but even so its going to take a couple weeks. If nodus seems pokey or the net connection to the outside world is too tight, then please let me and him know so that he can throttle the pipe a little.

  10565   Sun Oct 5 10:09:49 2014 ranaUpdateIOOIMC WFS measurements

It seems clever, but I wonder why use DTT and command line perl, instead of using the FE lockins or just demod the offline data or all of the other sensing matrix scripts made for the LSC (at 40m) or ASC (at LLO) ?

  10593   Fri Oct 10 00:20:37 2014 ranaUpdateLSCCARM W/N TFs

 

 Assuming that these Watts/Newtons TFs are correct, I've modeled the resulting open loop gain for CARM. The goal is to design a loop that is stable under a wide range of offsets and also has enough low frequency gain.

The attached PDF shows this. I used a CARM OLG Simulink model:

carm40.png

I've replaced the 'armTF' block with a digital gain of zero. After measuring the open loop gain of all but this piece, I multiply that 'OLG' with the W/N that Jenne extracted from Optickle for CARM->TR (not sqrtInv)

I plot the resulting estimate of the actual OLG in the following plot. Since the CARM-RSE peak is moving down, we use the LP filter that Den installed for us several months ago. To account for the radiation pressure spring, we use some low frequency boosts but not the crazy FM4 filter.

As you can see, the loop is stable from 500 to 200 pm, but then goes unstable around 110 pm. I expect that we will want to do some fancy shaping there or switch from TRX+TRY into something else.

This assumes we have filters 0, 1, 3, 5, and 7 on in the CARM filter bank - still need to add the digital AA/AI to make the loop phase lag a little more accruate, but I think this is looking promising.

 

  10604   Mon Oct 13 21:59:47 2014 ranaUpdateComputer Scripts / ProgramsWhich side of optical spring are we on? (No progress)

 

 Since no one was here, I started the Ubuntu 10 - 12 upgrade on Rossa. It didn't run at first because it wanted to remove 'update-manager-kde' even though it was on the blacklist. I removed it from the command line and now its running. Allegra, OTOH, refuses to upgrade. Someone please ask Diego to wipe it and then install Ubuntu 12 LTS on there in the morning...its a good way to learn the Martian CDS setup.

  10608   Wed Oct 15 02:59:04 2014 ranaUpdateLSCCARM W/N TFs

 In my previous elog in this thread, I showed the CARM OLG given some new digital filters and the varying CARM plant (spring side, not anti-spring). Jenne has subsequently produced the TFs for all of the rest of the CARM offsets.

These attached plots for several CARM offsets show that the anti-spring side is much more stable than the spring side and so we should use that. Annecadotedally, we think that positive CARM offsets are more stable when going to arm powers of > 10, so perhaps this means that +CARM = -SPRING.

The first PDF shows the spring OLGs and the 2nd one shows the antispring OLGs. I have put in some gain changes to keep the UGF approximately the same as the offset is changed.

The PDF thumbnails will become visible once Q and Diego install the new nodus.

 UPDATE OCt 16: this is all wrong! bad conversion of filters within the invbilinear.m function.

  10619   Thu Oct 16 21:20:59 2014 ranaUpdateLSCmisleading modelling

 I think these are all very helpful and interesting plots. We should see some better performance using either of the DC DARM signals.

BUT, what we really need (instead of just the DC sweeps) is the DC sweep with the uncertainty/noise displayed as a shaded area on the plot, as Nic did for us in the pre-CESAR modelling.

Otherwise, the DC sweeps mistakenly indicate that many channels are good, whereas they really have an RMS noise larger than 100 pm due to low power levels or normalization by a noisy signal.

  10620   Thu Oct 16 22:35:05 2014 ranaUpdateLSCCARM W/N TFs

In my last CARM loop modelling, all of the plots are phony, so don't trust them. The invbilinear function inside of StefanB's onlinefilter.m was making bogus s-domain representations of the digital filter coefficients.

So now I've just plotted the frequency response directly from the z-domain SOS coeffs using MattE's readFilterFile.m and FotonFilter.m.

Conclusions are less rosy. The anti-spring side is still easier to compensate than the spring side, but it starts to get hopeless below ~130 pm of offset, so there we really need to try to get to REFL_11/(TRX+TRY), pending some noise analysis.

** In order to get the 80 and 40 pm loops to be more stable I've put in a tweak filter called Boost2 (FM8). As you can see, it kind of helps for 80 pm, but its pretty hopeless after that.

  10631   Wed Oct 22 06:32:29 2014 ranaUpdateLSCsweep + RMS as uncertainty

 

 This is looking very useful. It will be useful if you can upload some python code somewhere so that I can muck with it.

I would guess that the right way to determine the trans RMS is just to use the single arm lock RIN and then apply that as RIN (not pure TR RMS) to the TR signals before doing the sqrt operation.

  10639   Fri Oct 24 18:53:23 2014 ranaUpdateGeneralY AUX laser - fiber coupled

 10% seems like a pretty bad coupling efficiency, even for a single lens. I know that the NPRO itself isn't so elliptical as that. Where is the other 230 mW going? random scattering?

Given that this is such an invasive process and, since its so painful to lose a whole night of locking due to end table business, I suggest that you always measure the out-of-loop ALS noise at the end of the end table work. Just checking that the green laser is locked to the arm is not sufficient to prove that the end table work won't prevent us from locking the interferometer.

We should insist on this anytime someone works on the optics or electronics at EX or EY. Don't have enough time to do an out-of-loop ALS spectrum? Then don't work at the end tables at all that day. We've got PZT alignment and mode matching work to do, as well as the rebuild of the EX table enclosure, so this is a good discipline to pick up now.

  10688   Sat Nov 8 11:31:51 2014 ranaUpdateComputer Scripts / ProgramsAnaconda + CDSutils

Quote:

I've fallen down the rabbit hole of trying to reconcile our desire for newer versions of the Numpy and Scipy python packages with the use of our handy cdsutils tools. 

 Avoid rabbit holes! What I did at LLO which works is to install an Anaconda in some shared directory and then just make an alias which puts that directory at the head of the path when running the more advanced SciPy installs. It works fine and cannot interfere with our usual operation since its only sourced when running peak find.

  10689   Sat Nov 8 11:35:05 2014 ranaUpdateLSC3F RFPD RF spectra

 

 I think 'saturation' here is a misleading term to think about. In the RF amplifiers, there is always saturation. What we're trying to minimize is the amount of distorted waveforms appearing at 3f and 15f from the other large peaks. Usually for saturation we are worried about how much the big peak is getting distorted; not the case for us.

  10694   Mon Nov 10 23:14:20 2014 ranaSummarySUSSRM: damping gains & Optical Lever servo Tune-up
  1.  tweaked gains for POS, PIT, YAW, SIDE by ~10-20% to get nice ringdowns with Q~5.
  2. Measured bounce rool freqs = 16.43 / 23.99 Hz. Updated the Mech Res Wiki page. Tightened up the bandstops to get back a few deg of phase. Propagated these new bandstops into the SRM SUS damping filter banks.
  3. Made and turned on a LP filters for the loops.
  4. Added a ~0.3 Hz gain boost / bubble.
  5. Set UGF to be ~2.5x below where it rings up. Estimate this to be ~3.5 Hz.
  6. First PDF shows bounce/roll peaks in OSEMs. Notice how f_roll is > sqrt(2)*f_bounce. ??
  7. Second PDF shows the OL spectra with the loops on/off. Previously there was no Boost and no LP (!!) turned on.
  8. 3rd PDF shows the modeled Bode plot of the OLG. yellow/blue is boost off/on
  10707   Thu Nov 13 01:00:37 2014 ranaUpdateLSCRIN in transmission a problem?

 

 I modified the MC2 trans optical setup a little bit: the reflection from the QPD was not dumped and so it was hitting the wall of the black box.

I angled the QPD slightly and moved the dump so that the reflection hit it. The leakage through the 50/50 steering mirror for the QPD was already being dumped and I made sure that that one stayed dumped on its razor dump. After doing this we turned off the WFS and re-aligned the MC2 trans beam onto the QPD to zero the pit/yaw signals. 

  10721   Sat Nov 15 21:51:09 2014 ranaUpdatePEMSeismometers set up for huddle test

  In order to do high quality huddle subtraction, we need to align the seismometer axes to high precision. We would need 1000x subtraction to see the instrument noise floor, but are likely to only get 100x. For that we need to align the axes to 0.5 deg (or do a Wiener coordinate transform with the data). To do this, we need to use a high quality bubble level and eventually iterate after trying out.

We should strain relieve the seismometer cables on the slab. It should be a tight clamp so that acoustic vibrations on the cables are terminated at the clamp and don't get to the seismometers. The clamp can be attached to the slab using some strong epoxy.

  10722   Mon Nov 17 20:28:17 2014 ranaSummaryIOOMC servo summing amp

I modified the /cvs/cds/caltech/target/c1psl/psl.db file to adjust the records for the FSS-FAST signal (to make it go yellow / red at the correct voltages). This was needed to match 5V offset which Koji added to the output of the FSS board back in August.

I also manually adjusted the alarm levels with caput so that we don't have to reboot c1psl. Beware of potential tiimebomb / boot issues if I made a typo! psl.db update in the SVN (also, there were ~12 uncomitted changes in that directory....please be responsible and commit ALL changes you make in the scripts directory, even if its just a little thing and you are too cool for SVN)

  10786   Thu Dec 11 22:44:23 2014 ranaUpdateLSCQPD screens

All of the QPDX matrix fields had a missing underscore in them. So I committed all of the c1asc screens to the SVN (because no one but me and Jamie seems to be able to remember to do this).

Then I did find/replace on the QPDY screen and saved it over the QPDX screen and committed the new thing to SVN as well. Values are now accessible.

  10795   Sat Dec 13 00:35:11 2014 ranaUpdateElectronicsXend QPD whitening board modified

 

 16 bit. There aren't any 14-bit ADCs anywhere in LIGO. The aLIGO suspensions have 18-bit DACs.

The Y-End gains seem reasonable to me. I think that we only use TRX/Y as error signals once we have arm powers of >5 so we should consider if the SNR is good enough at that point; i.e. what would be the actual arm motion if we are limited only by the dark noise?

I seem to remember that the estimate for the ultimate arm power is ~200, considering that we have such high losses in the arms.

  10800   Mon Dec 15 22:40:09 2014 ranaSummaryPSLPMC restored

 Found that the PMC gain has been set to 5.3 dB instead of 10 dB since 9 AM this morning, with no elog entry.

SadToastFace.jpg

I also re-aligned the beam into the PMC to minimize the reflection. It was almost all in pitch.

  10828   Mon Dec 22 15:11:08 2014 ranaUpdateIOOMC Error Spectra

che tristezza  

What we want is to have the high and low noise spectra on the same plot. The high noise one should be triggered by a high PC DRIVE signal.

  10842   Wed Dec 24 08:25:05 2014 ranaConfigurationIOOnotes on MC locking

 I've updated the scripts for the MC auto locking. Due to some permissions issues or general SVN messiness, most of the scripts in there were not saved anywhere and so I've overwritten what we had before. 

After all of the electronics changes from Monday/Tuesday, the lock acquisition had to be changed a lot. The MC seems to catch on the HOM more often. So I lowered a bunch of the gains so that its less likely to hold the HOM locks.

A very nice feature of the Autolocker running on megatron is that the whole 'mcup' sequence now runs very fast and as soon as it catches the TEM00, it gets to the final state in less than 2 seconds.

I've also increased the amplitude of the MC2 tickle from 100 to 300 counts to move it through more fringes and to break the HOM locks more often. Using the 2009 MC2 Calibration of 6 nm/count, this is 1.8 microns-peak @ 0.03 Hz, which seems like a reasonable excitation.

Using this the MC has relocked several times, so its a good start. We'll have to work on tuning the settings to make things a little spicier as we move ahead.

 

That directory is still in a conflicted state and I leave it to Eric/Diego to figure out what's going on in there. Seems like more fallout from the nodus upgrade:

controls@chiara|MC > svn up

svn: REPORT of '/svn/!svn/vcc/default': Could not read chunk size: Secure connection truncated (https://nodus.ligo.caltech.edu:30889)

  10844   Fri Dec 26 18:20:42 2014 ranaUpdateComputer Scripts / ProgramsFSS Slow servo thresh change

Quote:

 

In the plot it is shown the behaviour of the PSL-FSS_SLOWDC signal during the last week; the blue rectangle marks an approximate estimate of the time when the scripts were moved to megatron. Apart from the bad things that happened on Friday during the big crash, and the work ongoing since yesterday, it seems that something is not working well. The scripts on megatron are actually running, but I'll try and have a look at it.

I guessed that what was happening was that the SLOW servo settings were not restored to the right values after the code movements / reboots. The ON threshold for the servo was set at +6 counts and the channel is MC TRANS. Since the ADC noise on that channel is ~50 counts, this means that the servo keeps pushing the laser temperature off in some direction when the MC is unlocked.

I reset the threshold to +6666 counts (the aligned MC transmission is ~16000 for the  TEM00 mode) so that it only turns on when we're in a good locked state.

  10846   Mon Dec 29 21:30:25 2014 ranaUpdateGeneralrecovery
  1. Control room is at +66 F. Brrrr.
  2. Alignment of input beam into the IMC was wacky; locked on HOM.
  3. Re-aligned beam into the PMC first.
  4. Restarted mxstream for c1sus.
  5. Power cycled Martian router; all laptops were lost. Now better.
  6. Aligned launch beam from PSL to get onto the MCWFS better, MC is locking OK now. Moved MC SUS a little to get back to OSEM values from 6 days ago.
  7. Fixed LOCK_MC screen quad displays to be cooler.
  8. changed many of the ezcawrite calls in the mcup / mcdown to be 'caput -l' for more robustness. Still need ezcawrite for the binbary calls.
  9.  I didn't touch the mirrors on the MC REFL path, so we can still use that as a reference once the temperature returns to normal; the PSL room temp is down to 20C from 22 C a couple days ago.
  10. TRX values coming in to the LSC were frozen and the TRY_OUT16 was going to huge values even though camera flashes were reasonable. Tried restarting c1lsc model. No luck.
  11. Also tried shutdown -r now on c1lsc. No luck. Probably needs a RFM boot.
  12. Increased the FSS SLOW servo threshold to 9999 counts to avoid it running on some misaligned TEM01 mode locks. Increased the PID's I gain from 0.05 to 0.356 by tuning on some step responses as usual.
  13. By midnight the control room temperature is back around 71 F.
  10847   Tue Dec 30 00:46:05 2014 ranaUpdateIOOInvestigations into the mad PCDRIVE

Koji and I noticed that there was a comb* of peaks in the MC and FSS at harmonics of ~37 kHz. Today I saw that this shows up (at a much reduced level) even when the input to the MC board is disconnected.

It also shows up in the PMC. At nominal gains, there is just the 37 kHz peak. After tweaking up the phase shifter settings, I was able to get PMC servo to oscillate; it then makes a comb, but the actual oscillation fundamental is 1/3 of 37 kHz (some info on Jenne from elog 978 back in 2008).

Not sure what, if anything, we do about this. It is curious that the peak shows up in the MC with a different harmonic ratio than in the PMC. Any theories?

 

Anyway, after some screwing around with phase and amplitude of the RF modulation for the PMC from the phase shifter screen**, I think the gain is higher in the loop and it looks like the comb is gone from the MC spectrum.

Another clue I notice is that the PCDRIVE mad times often are coincident with DC shifts in the SLOWDC. Does this mean that its a flakiness with the laser? While watching the PCDRIVE output from the TTFSS interface board on a scope, I also looked at MIXER mon. It looks like many of the high noise events are associated with a broadband noise increase from ~50-140 kHz, rather than some specific lines. Don't know if this is characteristic of all of the noisy times though.

 

* this 'comb' had several peaks, but seem not be precise harmonics of each other: (f3 - 3*f1)/f3 ~ 0.1%

** I think we never optimized this after changing the ERA-5 this summer, so we'd better do it next.

 *** UPDATE: the second plot show the comparison between the new quiet and noisy states. Its just a broad bump.

 

  10848   Tue Dec 30 17:26:23 2014 ranaUpdatePSLRelaxation Osc and the NPRO Noise eater

I wonder if the variable bump around 100 kHz can be something about the NPRO and if the bump we see is the closed loop response due to the Noise Eater.

NE_Mephisto.png

This plot (from the Mephisto manual) shows the effect of the NE on the RIN, but not the frequency noise. I assume its similar since the laser frequency noise above 10 kHz probably just comes from the pump diode noise.

I went out to the PSL and turned off the NE at ~4:53 PM local time today to see what happened. Although the overall PCDRIVE signal looks more ratty, there is no difference in the spectra of ON/OFF when the PCDRIVE is low. When its noisy, I see a tiny peak around 1 MHz with NE OFF. Turned it back on after a few hours.

  10849   Tue Dec 30 20:35:59 2014 ranaSummaryPSLPMC Tune Up
  1. Calibrated the Phase Adjust slider for the PMC RF Modulation; did this by putting the LO and RF Mod out on the TDS 3034 oscope and triggering on the LO. This scope has a differential phase measurement feature for periodic signals.
  2. Calibrated the RF Amp Adj slider for the PMC RF Modulation (on the phase shifter screen)
  3. The PMC 35.5 MHz Frequency reference card is now in our 40m DCC Tree.
  4.  The LO and RF signals both look fairly sinusoidal !
  5. Took photos of our Osc board - they are on the DCC page. Our board is D980353-B-C, but there are no such modern version in any DCC.
  6. The PMC board's Mixer Out shows a few mV of RF at multiples of the 35.5 MHz mod freq. This comes in via the LO, and can't be gotten rid of by using a BALUN or BP filters.
  7. In installed the LARK 35.5 MHz BP filter that Valera sent us awhile ago (Steve has the datasheet to scan and upload to this entry). It is narrow and has a 2 dB insertion loss.

For tuning the phase and amplitude of the mod. drive:

- since we don't have access to both RF phases, I just maximized the gain using the RF phase slider. First, I flipped the sign using the 'phase flip' button so that we would be near the linear range of the slider. Then I put the servo close to oscillation and adjusted the phase to maximize the height of the ~13 kHz body mode. For the amplitude, I just cranked the modulation depth until it started to show up as a reduction in the transmission by ~0.2%, then reduced it by a factor of ~3. That makes it ~5x larger than before.

  10851   Sun Jan 4 22:08:46 2015 ranaUpdateIOOMC loop characterizations: PZT/EOM crossover

 * PMC + MC were unlocked when I came in.

* I fiddled around some more with the mcup/down scripts to make locking snappier. The locking was breaking the PMC lock often, so I re-enabled the MC servo board output limiter during acquisition. It is disabled in the MC UP script.

* Re-measured the MC OLG. Still OK.

* Measured the PZT / EOM crossover (aka the FAST / PC crossover) using the connectors on Koji's summing box. With the FAST gain at 18 dB, the crossover is ~10 kHz. Looks way to shallow. Plots to follow.

* I finally discovered today that the PMC PZT stroke is what's causing the main mis-alignment of the beam going to the IMC. By relocking at a few positions, I could see that the IOO QPDs have steps when the PMC relocks. So the IO beam wander is NOT due to temperature effects on the optics mounts of the PSL table. I wonder if we have a large amount of length to angle coupling or if this is the same as the OMC PZTs ?

P.S. I found that someone is using a temporary bench power supply to power the summing box between the TTFSS and the Thorlabs HV driver...whoever did this has ~48 hours to hook up the power in the right way or else Koji is going to find out and lose it and then you have to wear the Mickey Mouse hat.

http://www.arroyoinstruments.com/files/Arroyo-UsingBenchPowerSupplies_11Apr.pdf


The first attachment shows the OLG measurements with 2 different values of the fast gain (our nominal FG is 18 dB). You can see that the higher gains produce some crossover instability; when tuning the gain we notice this as an increase in the PCDRIVE rms channel.

The second attachment shows the measurement of the 'crossover'. Its really just the direct measurement of the IN1 / IN2 from the FAST summing box, so its the crossover measurement where the OLG is high.

  10874   Wed Jan 7 21:13:35 2015 ranaUpdateGeneralinane LSCoffsets script removed

Quote:

 A few things that I have neglected to ELOG yet:

  • scripts/offsets/LSCoffsets is a new script that uses ezcaservo to set FM offsets of our LSC PDs. It still warns about large changes, and lets you revert. It reads the FM gain to pick the right gain for the ezcaservo call. 

 We never, ever want to use ezcaservo to do this. IN fact, we twice have already deleted scripts where people have implemented these (sometimes) unstable servos. Also, since this change had never been committed to the SVN, I just deleted it and updated from the SVN to get back the script that doesn't use any servos.

I'm going to periodically delete locking scripts that are not committed to the SVN since anyone who is too lazy to use the SVN probably can't write code worth using.

  10899   Wed Jan 14 02:11:07 2015 ranaSummaryTreasure2-loop Algebra Loopology

I show here the matrix formalism to calculate analytically the loop TF relationships for the IMC w/ both FSS actuators so that it would be easier to interperet the results.

The attached PDF shows the Mathematica notebook and the associated block diagram.

In the notebook, I have written the single hop connection gains into the K matrix. P is the optical plant, C is the Common electronic gain, F is the 'fast' NPRO PZT path, and M is the phase Modulator.

G is the closed loop gain matrix. The notation is similar to matlab SS systems; the first index is the row and the second index is the column. If you want to find the TF from node 2 to node 3, you would ask for G[[3,2]].

As examples, I've shown how to get the FAST gain TF that I recently made with the Koji filter box as well as the usual OLG measurement that we make from the MC servo board front panel.

  10949   Wed Jan 28 14:19:02 2015 ranaUpdateLSCTransitioned DARM to AS55Q

Why AS55/(TRX + TRY) instead of just TRX? Isn't (TRX+TRY) controlled by CARM?cool

(question is secretly from Kiwamu)

  10988   Sun Feb 8 21:54:50 2015 ranaSummaryPSLISS AOM driver check

This is good news. It means that the driver probably won't limit the response of the loop - I expect we'll get 20-30 deg of phase lag @ 100 kHz just because of the acoustic response of the AOM PZT + crystal.

  10998   Wed Feb 11 00:07:54 2015 ranaUpdateLSCLock Loss plot

Here is a lock loss from around 11 PM tonight. Might be due to poor PRC signals.  \oint {\frac{\partial PRCL}{\partial x}}

This is with arm powers of ~6-10. You can see that with such a large MICH offset, POP22 signal has gone done to zero. Perhaps this is why the optical gain for PRCL has also dropped by a factor of 30 crying.

This seems untenable no. We must try this whole thing with less MICH offset so that we can have a reasonable PRCL signal.cool

  11002   Wed Feb 11 16:49:41 2015 ranaUpdateelogELOGD restarted

No elog response from outside and no elogd process frownon nodus, so I restarted it using 'start-elog.csh'.

  11008   Thu Feb 12 01:00:18 2015 ranaUpdateLSCRFPD spectra

The nonlinearity in the LSC detection chain (cf T050268) comes from the photodetector and not the demod board. The demod board has low pass or band pass filters which Suresh installed a long time ago (we should check out what's in REFL33 demod board). 

Inside the photodetector the nonlinearity comes about because of photodiode bias modulation (aka the Grote effect) and slew rate limited distortion in the MAX4107 preamp.

  11009   Thu Feb 12 01:43:09 2015 ranaUpdateLSCNew Locking Paradigm - LSC model changes

With the Y Arm locked, we checked that we indeed can get loop decoupling using this technique.

The guess filter that we plugged in is a complex pole pair at 1 Hz. We guessed that the DC gain should be ~4.5 nm count. We then converted this number into Hz and then into deg(?) using some of Jenne's secret numbers. Then after measuring, we had to increase this number by 14.3 dB to an overall filter module gain of +9.3.

The RED trace is the usual 'open loop gain' measurement we make, but this time just on the LSC-MC path (which is the POY11_I -> ETMY path).

The BLUE trace is the TF between the ALS-Y phase tracker output and the FF cancellation signal. We want this to be equal ideally.

The GREEN trace is after the summing point of the ALS and the FF. So this would go to zero when the cancellation is perfect.

So, not bad for a first try. Looks like its good at DC and worse near the red loop UGF. It doesn't change much if I turn off the ALS loop (which I was running with ~10-15x lower than nominal gain just to keep it out of the picture). We need Jenne to think about the loop algebra a little more and give us our next filter shape iteration and then we should be good.

  11018   Thu Feb 12 23:40:12 2015 ranaUpdateIOOBounce / Roll stopband filters added to MC ASC filter banks

The filters were already in the damping loops but missing the MC WFS path. I checked that these accurately cover the peaks at 16.5 Hz and 23.90 and 24.06 Hz.

ELOG V3.1.3-