40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 167 of 339  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  873   Sat Aug 23 09:39:51 2008 rana, jenneUpdatePSLPMC Survey
Jenne, Rana

We scoped out the PMC situation yesterday.

Summary: Not broke. UGF ~ 500 Hz. Needs some electronics work (notches, boosts, LPFs)

Ever since we swapped out the PMC because of the broken PZT of the previous one, the UGF has been
limited to a low value. This is because the notches no longer match the mechanical resonant
frequencies of the body. The old one had a resonance at 31.3 kHz which we were notching using
the LC notch on the board as well as a dangling Pomona box in the HV line to the PZT. The one
has a resonance at ~14.5 kHz which we don't yet have a notch for. Jenne has all the real numbers and
will update this entry with them.

Todo:
  • Implement the 4th order Grote low pass after the mixer.
  • Replace the AD797 with an OP27.
  • Change servo filter to have a boost (need DC gain)
  • Make a 14.5 kHz notch for the bode mode.
  • Put a 20 lb. gold-foil wrapped lead brick on the PMC.

Here's the link about the modified PMC board which we installed at LHO:
LHO PMC elog 2006
  4375   Thu Mar 3 20:30:03 2011 ranaSummaryPSLPMC Sweeps @ different input power levels to measure the Finesse

Its been well noted in the past that sweeping the PMC at high power leads to a distortion of the transmitted power curve. The explanation for this was coating absorption and thermo-elastic deformation of the front face of the mirrors.

Today, I did several sweeps of the PMC. I turned off its servo and tuned its PZT so that it was nearly resonating. Then I drove the NPRO via the HV driver (gain=15) with 0-150 V (its 1.1 MHz/V) to measure the PMC transmitted light. I adjusted the NPRO pump diode current from 2A on down to see if the curves have a power dependent width.

In the picasa web slideshow:

There are 3 significant differences between this measurement and the one by John linked above: its a new PMC (Rick says its the cleanest one around), the sweep is faster - since I'm using a scope instead of the ADC I feel free to drive the thing by ~70 MHz in one cycle. In principle, we could go faster, but I don't want to get into the region where we excite the PZT resonance. Doing ~100 MHz in ~30 ms should be OK. I think it may be that going this fast avoids some of the thermal distortion problems that John and others have seen in the past. On the next iteration, we should increase the modulation index for the 35.5 MHz sidebands so as to get a higher precision calibration of the sweep's range.

By eye I find that the FWHM from image #4 is 11 ms long. That corresponds to 300 mV on the input to the HV box and 15 V on the PZT and ~16.5 MHz of frequency shift. I think we expect a number more like 4-5 MHz; measurement suspicious.

  4417   Mon Mar 21 13:26:25 2011 KojiUpdatePSLPMC Trans/RFPDDC

PMC TRANS/REFL on MEDM showed red values for long time.
TRANS (a.k.a C1:PSL-PSL_TRANSPD) was the issue of the EPICS db.

REFL (a.k.a. C1:PSL-PMC_RFPDDC) was not physically connected.
There was an unknown BNC connected to the PMC DC output instead of dedicated SMA cable.
So they were swapped.

Now I run the following commands to change the EPICS thresholds:

ezcawrite C1:PSL-PMC_PMCTRANSPD.LOLO 0.8
ezcawrite C1:PSL-PMC_PMCTRANSPD.LOW 0.85
ezcawrite C1:PSL-PMC_PMCTRANSPD.HIGH 0.95
ezcawrite C1:PSL-PMC_PMCTRANSPD.HIHI 1

ezcawrite C1:PSL-PMC_RFPDDC.HIHI 0.05
ezcawrite C1:PSL-PMC_RFPDDC.HIGH 0.03
ezcawrite C1:PSL-PMC_RFPDDC.LOW 0.0
ezcawrite C1:PSL-PMC_RFPDDC.LOLO 0.0

As these commands only give us the tempolary fix, /cvs/cds/caltech/target/c1psl/psl.db was accordingly modified for the permanent one.

grecord(ai,"C1:PSL-PMC_RFPDDC")
{
        field(DESC,"RFPDDC- RFPD DC output")
        field(DISV,"1")
        field(SCAN,".1 second")
        field(DTYP,"VMIVME-3113")
        field(INP,"#C0 S32 @")
        field(EGUF,"10")
        field(EGUL,"-10")
        field(EGU,"Volts")
        field(PREC,"3")
        field(LOPR,"-10")
        field(HOPR,"10")
        field(AOFF,"0")
        field(LINR,"LINEAR")
        field(LOW,"0.0")
        field(LSV,"MINOR")
        field(LOLO,"0.0")
        field(LLSV,"MAJOR")
        field(HIGH,"0.03")
        field(HSV,"MINOR")
        field(HIHI,"0.05")
        field(HSV,"MAJOR")
}

grecord(ai,"C1:PSL-PMC_PMCTRANSPD")
{
        field(DESC,"PMCTRANSPD- pre-modecleaner transmitted light")
        field(DISV,"1")
        field(SCAN,".1 second")
        field(DTYP,"VMIVME-3123")
        field(INP,"#C0 S10 @")
        field(EGUF,"10")
        field(EGUL,"-10")
        field(EGU,"volts")
        field(PREC,"3")
        field(LINR,"LINEAR")
        field(HOPR,"10")
        field(LOPR,"-10")
        field(AOFF,"0")
        field(LOW,"0.8")
        field(LSV,"MINOR")
        field(LOLO,"0.85")
        field(LLSV,"MAJOR")
        field(HIGH,"0.95")
        field(HSV,"MINOR")
        field(HIHI,"1.00")
        field(HSV,"MAJOR")
}

  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.

Attachment 1: 17.png
17.png
Attachment 2: PMCcal.ipynb.xz
Attachment 3: PMC_Osc_Cal.pdf
PMC_Osc_Cal.pdf
  15144   Thu Jan 23 14:37:05 2020 gautamUpdatePSLPMC VGA chip damaged?

[jordan, gautam]

Summary:

The AD602 chip which implements the overall servo gain for the PMC seems to be damaged. We should switch this out at the next opportunity.

Details:

  1. According to the PSL cross connect wiring diagram, the VME DAC that provides the control voltage to the VGA stage goes to pins 7/8 of cross connect J16.
    • Jordan and I verified that the voltage at this point [Vout], is related to the PMC_GAIN EPICS slider [dB] value according to the following relationship: V_{\mathrm{out}} = (10-\mathrm{dB})/2.
  2. On the PMC servo board, this voltage is scaled by a factor of -1/10. 
    • This was confirmed by peeking at this voltage using a DMM (I clipped onto R31) while the gain slider was varied.
    • This corresponds to +/- 1000 mV reaching the AD602.
    • However, the AD602 is rated to work with a control voltage varying between +/- 625 mV.
    • What this means is that the EPICS slider value is not the gain of the AD602 stage. The latter is given by the relation G [\mathrm{dB}] = 32 \times V_{\mathrm{G}} + 10.
    • @team PSL upgrade: this should be fixed in the database file for the new c1psl machine.
  3. Using TP1 and TP2 connected to the SR785, I measured the transfer function of the AD602 for various values of the EPICS slider.
    • Result is shown in Attachment #1.
    • I did this measurement with the PMC locked, so I'm using the in-loop error signal to infer the gain of the VGA stage.
    • As expected, the absolute value of the gain does not match that of the EPICS slider (note that the AD602 has an input impedance of 100 ohms. So the 499 ohm series resistor between TP1 and the input of AD602 makes a 1/5 voltage divider, so the gain seen between TP1 and TP2 has this factor folded in).
    • Moreover, the relative scaling of the gain for various slider values also doesn't appear to be liner.
    • For the highest gain setting of +15 dB, the servo began oscillating, so I think the apparent non-flatness of the gain as a function of frequency is an artefact of the measurement.
    • Nevertheless, my conclusion is that the IC should be changed.

I will pull the board and effect the change later today.

I pulled the board out at 345pm after dialling down all the HV supplies in 1X1. I will reinstall it after running some tests.

Attachment 1: VGAchar.pdf
VGAchar.pdf
  15146   Thu Jan 23 16:37:14 2020 ranaUpdatePSLPMC VGA chip damaged?

doesn't seem so anomolous to me; we're getting ~25 dB of gain range and the ideal range would be 40 dB. My guess is that even thought this is not perfect, the real problem is elsewhere.

  1877   Mon Aug 10 16:41:31 2009 AlbertoConfigurationPSLPMC Visibility

Alberto, Rana

lately we've been trying to better understand what's preventing the arm power to get high again. Last week I tuned the MZ and the PMC but we didn't gain much, if nothing at all.
Yesterday I measured the transmissivity, the reflectivity and the visibility of the PMC.
 
From the voltages at the PMC-REFL PD when the PMC was locked and when it was out of lock I estimated the cavity visibility:
V_locked = 0.42V
V_unlocked = 1.64V -> V = (V_unlocked - V_locked) / V_unlocked = 75%

With the high power meter I measured the reflected power when the PMC was unlocked and used that to obtain the calibration of the PMC-REFL PD: 1.12V/W.

Since the locked-cavity reflected power can't be directly measured with a power meter (since that would use the cavity control signal), I estimated the reflected power by the calibration of the PMC-REFL PD. Then I measured the input and the transmitted power with a high-power meter.
Result:

P_in = 1.98W ; P_trans = 1.28W ; P_refl = 0.45W

From that I estimated that the losses account to 13% of the input power.

I checked both the new and the old elogs to see if such a measurement had ever been done but it doesn't seems so. I don't know if such a value for the visibility is "normal". It seems a little low. For instance, as a comparison, the MC visibility, is equal to a few percents.

Also Rana measured the transmitted power after locking the PMC on the TEM20-02: the photodiode on the MEDM screen read 0.325V. That means that a lot of power is going to that mode.

That makes us think that we're dealing with a mode matching problem with the PMC.

  10742   Mon Dec 1 17:19:22 2014 JenneUpdateGeneralPMC align

[Diego, Jenne]

Tweaked up the input alignment to the PMC.  Now we're at 0.785.

  4648   Thu May 5 20:47:41 2011 KojiUpdatePSLPMC aligned

The PMC exhibited the reduction of the transmission, so it was aligned.

The misalignment was not the angle of the beam but the translation of the beam in the vertical direction
as I had no improvement by moving the pitch of one mirror and had to move those two differentially.

This will give us the information what is moving by the temperature fluctuation or whatever.

  5644   Mon Oct 10 15:41:56 2011 KojiUpdatePSLPMC aligned

[Koji Suresh]

The steering mirrors for PMC were aligned. The transmission went up from 0.779 to 0.852.

  6569   Wed Apr 25 19:36:19 2012 DenUpdatePSLPMC aligned

[Koji, Den]

We have aligned PMC,  the WFS are not working yet.

  7273   Fri Aug 24 20:48:10 2012 KojiUpdatePSLPMC aligned

as usual.

  9256   Mon Oct 21 13:15:52 2013 KojiUpdateIOOPMC aligned

PMC aligned. Trans 0.78 -> 0.83

  10950   Wed Jan 28 17:32:26 2015 KojiUpdatePSLPMC aligned

PMC aligned.

PMC Trans increased from 0.740 to 0.782

IMC Trans increased from 16200 to 17100

  8470   Mon Apr 22 12:03:58 2013 KojiUpdatePSLPMC aligned too

PMC aligned. C1:PSL-PMC-PMCTRANSPD improved from 0.72ish to 0.835ish.

  2168   Mon Nov 2 13:00:55 2009 KojiUpdateIOOPMC aligned, MC WFS aligned

The beam to PMC aligned. The beam to MC WFS cameras aligned.
PMC Trans increased from 2.73 to 2.75 (+1%).
MC Trans increased from 7.80 to 7.87 (+1%).

  12792   Thu Feb 2 18:32:51 2017 ranaSummaryPSLPMC alignment

Re-aligned the beam going into the PMC today around 5 PM. I noticed that its all in pitch and since I moved both of the mirrors by the same amount it is essentially a vertical translation.

I wonder if the PMC is just moving up and down due to thermal expansion in the mount? How else would we get a pure vertical translation? Need to remember next time if the beam goes up or down, and by how many knob turns, and see how it correlates to the lab temperature.

  7382   Fri Sep 14 00:33:31 2012 ranaUpdatePSLPMC alignment - mystery in reflected power

The PMC reflection made it seem that the beam going into it was misaligned. I went to the table and aligned the input beam to maximize the PMC transmission. I got ~10% improvement.

Just to check if something was loose, I started tapping things upstream of the Faraday. When I tapped the actual PMC body it seemed to get unseated and the reflected (unlocked) power jumped up by more than a factor of two.

I don't understand how this could be. The attached trend of the PMC channels shows that ever since the PSL upgrade, the PMC refl has been at the low level of ~0.3 V, except for a brief phase soon after the upgrade late in 2010 and then also for a few hours early in May of 2012.

If the PMC body actually moved, it seems that the pointing into the MC would also change and I don't see that. So what else can it be? Is there some clipping or dust or a burn spot on the PMC REFL path?

The PMC refl image was lost after the body re-settled itself. Jenne and I re-aligned it and added a 0.5 ND filter to the existing ND in order to account for the higher power. We should hide all of the reflective ND filters and just use absorbtive ND for the cameras to prevent reflections.

a.png

This image of the past hour shows the event at just before midnight (0650 UTC) where the PMC reflection goes up from 0.28 to 0.85.

Attachment 1: pmcr.jpg
pmcr.jpg
Attachment 2: e.png
e.png
  7292   Tue Aug 28 00:23:54 2012 JenneUpdatePSLPMC alignment going bad

PMC transmission started going down this afternoon, around 3pm-ish.  Right now it's 0.775, which is very, very low.  The new MC locking stuff is engaged, so it's not the FSS slow servo's fault. 

EDIT: I just realized that the limit of 0 counts output of the MC2 MCL filter bank was still engaged, from a time earlier this afternoon when I had switched back to the old servo, so there was no feedback going back to keep the slow drift of the laser in check.  PMC trans isn't coming back instantly, so I'll check it again when I come in tomorrow.

Attachment 1: PMC_transmission_GoingDown_27Aug2012.png
PMC_transmission_GoingDown_27Aug2012.png
  7294   Tue Aug 28 11:28:31 2012 ericqUpdatePSLPMC alignment going bad

Quote:

PMC transmission started going down this afternoon, around 3pm-ish.  Right now it's 0.775, which is very, very low.  The new MC locking stuff is engaged, so it's not the FSS slow servo's fault. 

EDIT: I just realized that the limit of 0 counts output of the MC2 MCL filter bank was still engaged, from a time earlier this afternoon when I had switched back to the old servo, so there was no feedback going back to keep the slow drift of the laser in check.  PMC trans isn't coming back instantly, so I'll check it again when I come in tomorrow.

 

By adjusting the PMC steering mirrors, Jenne and I realigned the PMC input beam. Transmission is at 0.829 now. 

  692   Thu Jul 17 20:13:34 2008 YoichiUpdatePSLPMC alignment/mode matching effort
I'm working to improve the mode matching of PMC.
Because I noticed that the beam was hitting the aperture of the EOM for PMC, I moved the EOM a little bit to maximize the transmission.
This did not change the alignment to the reference cavity but changed the alignment of the PMC a lot.
So I adjusted it back.
The alignment of the PMC can be easily optimized but the Hermite 02 mode still remains. This means the mode matching is bad.
Moving the lenses by a small amount (a few mm) did not change the height of 02 mode.
I'm planning to move the lenses by a large amount tomorrow. But it will destroy the alignment to the PMC.
So I installed two irises in the beam path after the lenses to remember the alignment roughly.
Right now the PMC transmission is slightly worse than before because the lens positions are not good.
  7501   Mon Oct 8 11:15:53 2012 JenneUpdatePSLPMC and FSS had a weird weekend

Something bizarre-o was going on with the PMC and FSS over the weekend.  On the striptool, PMC's PZT looks like it was doing a sawtooth pattern for several hours.  I opened up the FSS screen, and the FSS SLOWDC had walked itself up to +10.  It's not supposed to get that far from 0. 

Here are some trends, so you can see what was going on.

10 day trend:  This weird behavior began ~Friday evening (FSS_SLOWDC ramps quickly).

PMC_sawtooth_FSSweird_8Oct2012_10dayTrend.png

1 day trend:  You can see the sawtooth pattern in PMC_PZT more clearly here.  It's at the same time as the FSS_SLOWDC is ramping rapidly, and the FSS_FAST is saturated.

PMC_sawtooth_FSSweird_8Oct2012_1dayTrend.png

Attachment 2: PMC_sawtooth_FSSweird_8Oct2012_1dayTrend.png
PMC_sawtooth_FSSweird_8Oct2012_1dayTrend.png
  14696   Tue Jun 25 15:32:16 2019 gautamUpdateIOOPMC and IMC locked again, some MEDM maintenance

Aaron complained to me earlier that the PMC could not be locked. Turned out to be a classic sticky slider problem, I keyed the c1psl VME crate, and did the usual burtrestore trick. After that, I could immediately lock the PMC and IMC with the nominal gain settings.

I also looked at the wiring at the rack. An SLP250 was installed at the mixer IF output, in parallel with a 50 ohm terminator to ground. I removed this, because as Aaron pointed out, the PMC servo card "FP1 TEST" input is already 50 ohm, and has two cascaded LC filter stages immediately after to filter out the 2f component, so the extra low-pass filtering is superfluous (in any case, 250 MHz is much too high a cutoff to be using for cutting out the 2f component which will be at ~70 MHz).

Finally, in the last ~2 weeks, we have been running with the PMC servo gain of +17 (as opposed to +18 from before). The old gain is too high, as noted by Milind. But the MEDM field for this gain goes RED unless the gain is +18. I adjusted the value of the  C1:PSL-STAT_PMC_NOM_GAIN channel to +17, so that this is no longer the case. I also edited the PMC MEDM screen to get rid of my comment that the "SLOW ADC IS DEAD" for the PMC TRANS field, since I have now hooked up the PMC trans photodiode to our temporary Acromag box.

Attachment 1: PMCctrl.png
PMCctrl.png
  14699   Wed Jun 26 10:55:13 2019 aaronUpdateIOOPMC and IMC locked again, some MEDM maintenance

The PMC was locking again after Gautam's steps above. However, after I added the directional coupler between the mixer I and the servo card (coupled to the Agilent analyzer), the PMC was again not locking, except occasionally with gain of -10 dB.

I removed the coupler (so the mixer I goes directly to the PMC servo card, as Gautam had it), and the PMC was still not locking. While checking connections, I noticed that one of the SMA cables between the LO and the mixer was not even finger tight, so I tightened them to approximately the right torque with a non-torque wrench.

This did not lead to the PMC locking, so Millind helped me key the c1psl VME crate. I burt restored the latest snapshot. Now, the PMC locks up until gain of -5. I try burt restoring the previous snapshot, which was from when the PMC was locking, and now it locks. Adding in the directional coupler again leads to the PMC not locking, though this time removing the coupler restores the normal behavior. I also tried using the coupler with the coupling port connected to a 50 Ohm terminator, and this configuration also did not lock.

I had been using a ZFDC-20-5-S+ (0.1-2000 MHz) with SMA ports and SMA-to-BNC on the input and output ports (since the mixer has BNC connectors). To reduce the number of potentially flaky connections, I am trying the ZFDC-20-4 (1-1000 MHz) that I found with BNC ports. The PMC still doesn't lock.

To get some spectrum, I've connected the PMC servo card's 'mixer out' to the Agilent's A channel, and collected a spectra from [10 Hz, 75 kHz], [75 kHz, 750 kHz], and [750 kHz, 2 MHz].


Wed Jun 26 15:23:37 2019

After the lab cleaning, I added a BNC T on the mixer I port, so now the configuration is:

Mixer I -> BNC T

-> PMC Servo card FP1TEST

-> directional coupler -> coupled to the spectrum analyzer, out port is terminated with 50 Ohms.

I thought maybe the issue was that the TF from in->out on the directional coupler is not what I expect (and Gautam suggested the in-out port might block DC), but the PMC still does not lock in the above configuration, in which the coupler is not between the mixer and the servo board--so only reflections from the coupler should matter, I think.

However, even when I plug the mixer directly into the servo board, the PMC is not locking (again) with gain above -8 dB or so. I did a burt restore again, and this fixed the problem. I wasn't sure why this burt restore is working, because all I am changing is the DC output adjust voltage and the gain, and switching on/off FP1TEST. However, I observed that after running the PMC autolocking script, observing that the autolocker did not achieve lock as it swept through resonance, and cancelling the autolocker, the PMC again cannot be locked for high gains. When I let the autolocker complete, this doesn't happen, so probably I'm just not letting some channel return to its nominal value after being changed by the autolocker.

Now after another burt restore, I'm avoiding using the autolocker and am still having trouble locking with the BNC T + directional coupler configuration above. However, now I'm noticing that the PZT control mon is always railed, as long as FP1TEST is in the loop (and independent of the output adjust voltage). I try returning to the 'baseline' configuration (mixer -> PMC servo card directly), and the PMC locks but with only 0.68 V transmission (was >0.7 V before).


Per Gautam's earlier suggestion, I switched to using the Agilent 41800A probe instead of the directional coupler. I was able to lock the OMC with this probe on a BNC T coming out of the mixer (transmission is 0.71 V). I recorded the spectra of the PMC servo board's "Mixer Out" channel, and the mixer's I as seen by the probe. I recorded spectra from 10 Hz to 100 MHz. The soft linked netgpibdata folder I had in my users directory is no longer soft linked--presumably intentional so I don't tamper with it?

I'm a bit skeptical that I've used the probe correctly, so I'm checking out the manual.

Indeed, I needed to pull back the sheath; I also noticed that the GPIB script I've been using doesn't save the data from both channels when I take a spectrum in dual mode, so I'm taking the spectra again one at a time (lights are on, IMC is locked).

  14700   Wed Jun 26 11:11:40 2019 MilindUpdateIOOPMC and IMC locked again, some MEDM maintenance

After helping Aaron key the crate and do a burt restore, I realized that it would probably be best to record the steps that Koji showed me to do a burt restore as a reference for (anyone) the future

Commands (in terminal):

  1. burttoday: changes to the directory with snapshots for the day (/opt/rtcds/caltech/c1/burt/autoburt/today)
  2. burtgooey: opens a new window with several buttons of which "Restore" needs to be selected. This opens up a second window as shown in Attachment #1. Click on Snapshot files and navigate to the snapshot you wish to restore (these are present at /opt/rtcds/caltech/c1/burt/autoburt/snapshots) and select that. A green "OK" button indicates if the Restore can be performed without a hitch. Hit "Restore" to perform the burtrestore.

 

Also Gautam explained today that the sticky slider problem is a hardware issue. That it basically means that the signal (voltage output for instance) that you request from the medm screen is not what the hardware delivers. Twice now, we have got around that with a burtrestore. My understanding of a burt restore is that it is a restoration of values from a certain time to the EPICS channels. Therefore, I don't understand why a restoration at the software level should fix how the hardware responds? Why does this happen?

Attachment 1: burtgooey.pdf
burtgooey.pdf
  14701   Wed Jun 26 18:28:24 2019 ranaUpdateIOOPMC and IMC locked again, some MEDM maintenance

a useful piece of code that we should ask one of this summer's SURFs to write:

  1. read in a BURT .req file which is usually used to make the autosnap / restore.
  2. change ALL of the values to some value (slightly different from its current value)
  3. restore it to its current value

this will solve the sticky slider problem and do it in a systematic way. We can run it from the command line: e.g. 'unsticky.py c1psl c1ioo c1lsc'

Quote:

Aaron complained to me earlier that the PMC could not be locked. Turned out to be a classic sticky slider problem,

  14711   Sun Jun 30 22:21:07 2019 MilindUpdateIOOPMC and IMC locked again, some MEDM maintenance

Wrote the script. It currently lives at /users/milind/NonlinearControl/milind/unstick/unstick.py. Also pushed it to the repo here. It does the following:

  1. When run as python unstick.py c1aux (for instance) from the terminal, it parses the autoBurt.req file at /cvs/cds/caltech/target/c1aux/autoBurt.req and obtains the channels.
  2. Iterates through the channels and changes it to "some value"
    1. For channels corresponding to buttons on MEDM screen (Enable/Disable etc.) toggles between 0 and 1
    2. For channels corresponding to continuous values (such as say exposure time or the like) changes to abs(1+current_value)
  3. Resets to original value and then moves to the next channel

I tried print statements instead of actually writing to the channels as Gautam asked me to do that with supervision. Is this good enough?

Quote:

a useful piece of code that we should ask one of this summer's SURFs to write:

  1. read in a BURT .req file which is usually used to make the autosnap / restore.
  2. change ALL of the values to some value (slightly different from its current value)
  3. restore it to its current value

this will solve the sticky slider problem and do it in a systematic way. We can run it from the command line: e.g. 'unsticky.py c1psl c1ioo c1lsc'

Quote:

Aaron complained to me earlier that the PMC could not be locked. Turned out to be a classic sticky slider problem,

  14712   Sun Jun 30 23:52:09 2019 KojiUpdateIOOPMC and IMC locked again, some MEDM maintenance

> For channels corresponding to continuous values (such as say exposure time or the like) changes to abs(1+current_value)

Why abs? Is the current_value is like -5.4321 (for example for the alignment slider), this returns +4.4321 and the suspension will suffer from huge motion (well it will be returned to the original value soon though). 

  14713   Mon Jul 1 11:02:05 2019 MilindUpdateIOOPMC and IMC locked again, some MEDM maintenance

Made changes as discussed in this issue. Further, I need to add signal handling capabilities to the code. I belive Jon has pointed me to some code. I will take a look at that ASAP.

Quote:

> For channels corresponding to continuous values (such as say exposure time or the like) changes to abs(1+current_value)

Why abs? Is the current_value is like -5.4321 (for example for the alignment slider), this returns +4.4321 and the suspension will suffer from huge motion (well it will be returned to the original value soon though). 

  13703   Mon Mar 26 10:15:20 2018 ArijitUpdateIOOPMC and IMC re-locked

[Gautam, Arijit]

PMC and IMC re-aligned and re-locked. Both cavities are staying locked. Arm cavities are also locked.

  14198   Mon Sep 17 12:28:19 2018 gautamUpdateIOOPMC and IMC relocked, WFS inputs turned off

The PMC and IMC were unlocked. Both were re-locked, and alignment of both cavities were adjusted so as to maximize MC2 trans (by hand, input alignment to PMC tweaked on PSL table, IMC alignment tweaked using slow bias voltages). I disabled the inputs to the WFS loops, as it looks like they are not able to deal with the glitching IMC suspensions. c1lsc models have crashed again but I am not worrying about that for now.

9pm: The alignment is wandering all over the place so I'm just closing the PSL shutter for now.

  14200   Tue Sep 18 17:56:01 2018 not gautamUpdateIOOPMC and IMC relocked, WFS inputs turned off

I restarted the LSC models in the usual way via the c1lsc reboot script. After doing this I was able to lock the YARM configuration for more noise coupling scripting.

Quote:

The PMC and IMC were unlocked. Both were re-locked, and alignment of both cavities were adjusted so as to maximize MC2 trans (by hand, input alignment to PMC tweaked on PSL table, IMC alignment tweaked using slow bias voltages). I disabled the inputs to the WFS loops, as it looks like they are not able to deal with the glitching IMC suspensions. c1lsc models have crashed again but I am not worrying about that for now.

9pm: The alignment is wandering all over the place so I'm just closing the PSL shutter for now.

 

  9175   Mon Sep 30 13:02:51 2013 Masayuki,ManasaUpdateIOOPMC and MC alignment

[Manasa, Masayuki]

The MC lost lock around 8+hrs ago. The transmission from PMC was 0.77 this morning, so we aligned the PSL to the PMC using the two steering mirrors before the PMC. We brought the PMC transmission to 0.841. We also aligned the MC, and the MC transmission reflection now is 0.59.

  6107   Mon Dec 12 15:24:21 2011 JenneUpdatePSLPMC and MC were both crappy - now realigned

PMC trans was only ~0.79, where it should be ~0.84 something.  The MC was also not stellar. 

I aligned the beam to the PMC, and am now getting PMC trans 0.837 .

Then I aligned the PSL zigzag to the MC, and got MC Refl down to ~0.6 . 

I then aligned the WFS to the unlocked MC, and the MC Trans QPD to the locked MC.

Things seem good.  MC axis is still in a good place, since we get good michelson fringes at the AS port.

  297   Tue Feb 5 15:32:29 2008 josephbConfigurationCamerasPMC and the GigE Camera
The PMC transmission video camera has been removed and replaced with the GigE GC750 camera for the moment.

A ND4.0 filter has been added in the path to that camera to reduce saturation for the moment.

The old camera has been placed on the elevated section inside the enclosure, and the cable for it is still on the table proper.

The Gige camera is currently running the Snap code on Linux3 with the following command line:

./Snap -E 2000 -l 60 -m 1440 -f './pmc_trans/pmc_trans'

So its going to be taking tiff images every minute for the next 24 hours into the cvs/cds/caltech/target/Prosilica/40mCode/pmc_trans/ directory.

Attached is an example image with exposure set to 2000, loaded into matlab and plotted with the surf command. 2500 microseconds looked like it was still saturating, but this seems to be a good level (with a max of 58560 out of 65535).
Attachment 1: pmc_trans.jpg
pmc_trans.jpg
  15498   Tue Jul 21 16:41:46 2020 gautamUpdateBHDPMC assembly space

I decided to use the old EY auxiliary optics table, which is now stored along the east arm about 10 m from the end, as a workspace for assembling the little PMCs. I wiped everything down with isopropanol for general cleanliness, removed the metal plate on the south edge of the table enclosure to allow access, covered the table with some clean Aluminium foil, and then moved the plastic box with PMC parts to the table - see Attachment #1. I haven't actually done any assembly just yet, waiting for more info (if available) on the procedure and implements available...

Attachment 1: IMG_8635.JPG
IMG_8635.JPG
  9333   Mon Nov 4 09:03:21 2013 SteveUpdatePSLPMC auto locker

Quote:

 I was working on the electronics bench and what sounded like a huge truck rolled by outside. I didn't notice anything until now, but It looks like something became misaligned when the truck passed by (~6:45-6:50 pm). I can hear a lot of noise coming out of the control room speakers and pretty much all of the IOO plots on the wall have sharp discontinuities.

I haven't been moving around much for the past 2 hours so I don't think it was me, but I thought it was worth noting.

 The PMC auto locker is not set to acquire error message made me lock PMC manually.  Arms  locked instantly: TRY 0.9 V and TRX 0.65 V

Attachment 1: 3dTREND.png
3dTREND.png
  6670   Thu May 24 01:17:13 2012 DenUpdateCDSPMC autolocker

Quote:

 

  • SCRIPT
    • Auto-locker for PMC, PSL things - DEN

 I wrote auto-locker for PMC. It is called autolocker_pmc, located in the scripts directory, svn commited. I connected it to the channel C1:PSL-PMC_LOCK.  It is currently running on rosalba. MC autolocker runs on op340m, but I could not execute the script on that machine

op340m:scripts>./autolock_pmc
./autolock_pmc: Stale NFS file handle.

I did several tests, usually, the script locks PMC is a few seconds. However, if PMC DC output has been drift significantly, if might take longer as discussed below.

The algorithm:

       if autolocker if enabled, monitor PSL-PMC_PMCTRANSPD channel
       if TRANS is less then 0.4, start locking:
               disengage PMC servo by enabling PMC TEST 1
               change PSL-PMC_RAMP unless TRANS is higher then 0.4 (*)
               engage PMC servo by disabling PMC TEST 1
       else sleep for 1 sec
 

(*) is tricky. If RAMP (DC offset) is specified then TRANS will be oscillating in the range ( TRANS_MIN, TRANS_MAX ). We are interested only in the TRANS_MAX. To make sure, we estimate it right, TRANS channel is read 10 times and the maximum value is chosen. This works good.

Next problem is to find the proper range and step to vary DC offset RAMP. Of coarse, we can choose the maximum range (-7, 0) and minimum step 0.0001, but it will take too long to find the proper DC offset. For that reason autolocker tries to find a resonance close to the previous DC offset in the range (RAMP_OLD - delta, RAMP_OLD + delta), initial delta is 0.03 and step is 0.003. It resonance is not found in this region, then delta is multiplied by a factor of 2 and so on. During this process RAMP range is controlled not to be wider then (-7, 0).

The might be a better way to do this. For example, use the gradient descent algorithm and control the step adaptively. I'll do that if this realization will be too slow.

I've disabled autolocker_pmc for the night.

  14680   Mon Jun 17 22:19:04 2019 MilindUpdateComputer Scripts / ProgramsPMC autolocker

As Rana asked me to in the last meeting, I dug through the elogs to determine what had become of the previous autolockers. I stumbled upon this elog by Rana from before Gautam cleaned up the medm screen. Out of curiosity, I ran the autolocker script using the instructions in Rana's elog. I did this a total of 5 times and could lock the PMC 3 times fairly quickly. I attempted to decipher the details of the code but did not make much headway owing to my unfamiliarity with the language. From what I could make out from the medm screen while the autolocker was running, it appeared to be the same method as that in this elog. I will take a look at it again tomorrow. However, I intend to spend most of tomorrow working on preprocessing the data, developing the CNN script and then the simulation. 

Quote:
 
  1.  I shall also begin working on a script to autolock the PMC based on what Rana showed me on Monday. I will also take a look at the the contents of this elog and try to pick up from there. I hope to make significant progress by the next lab meeting.

  14715   Mon Jul 1 20:18:01 2019 MilindUpdateComputer Scripts / ProgramsPMC autolocker

I've begun working on this. Steps to complete:

  1. Convert the autolocker to python. Test that it works.
  2. Run the script with different settings of the servo gain adjust and DC output adjust parameters and obtain a plot of the average time of lock to determine what the best settings of the aforementioned parameters are.
Quote:

As Rana asked me to in the last meeting, I dug through the elogs to determine what had become of the previous autolockers. I stumbled upon this elog by Rana from before Gautam cleaned up the medm screen. Out of curiosity, I ran the autolocker script using the instructions in Rana's elog. I did this a total of 5 times and could lock the PMC 3 times fairly quickly. I attempted to decipher the details of the code but did not make much headway owing to my unfamiliarity with the language. From what I could make out from the medm screen while the autolocker was running, it appeared to be the same method as that in this elog. I will take a look at it again tomorrow. However, I intend to spend most of tomorrow working on preprocessing the data, developing the CNN script and then the simulation. 

Quote:
 
  1.  I shall also begin working on a script to autolock the PMC based on what Rana showed me on Monday. I will also take a look at the the contents of this elog and try to pick up from there. I hope to make significant progress by the next lab meeting.
  14717   Tue Jul 2 12:30:44 2019 MilindUpdateComputer Scripts / ProgramsPMC autolocker

Just finished a raw version of the autolocker!! Tested it once and was able to achieve lock! This is a python version of the code at /opt/rtcds/caltech/c1/scripts/PSL/PMC/AutoLock.sh.

The current code lives in my users directory. Gautam asked me to put the completed autolocker at /opt/rtcds/caltech/c1/scripts/PSL/PMC/ and that I needn't necessarily put it on git. However, I had previously added it to my Non-linear control repo. Not sure if I should take it off? The current script still lacks some checks like those that enable it to stop after a certain time of attempting to lock or those that handle interrupt signals. Will do that in some time.

P.S. As Koji says, Victory! :-P

P.P.S. Rana pointed out that this is not the objective and what we actually wanna do is run a search over the parameter space of the locking process. I will document my ideas about this process as soon as I do a little more reading. He also said that it would not do to have command line arguments as the main source from which parameters are procured and that .yml files ought to be used instead. I will make that change asap.

 

Quote:

I've begun working on this. Steps to complete:

  1. Convert the autolocker to python. Test that it works.
  2. Run the script with different settings of the servo gain adjust and DC output adjust parameters and obtain a plot of the average time of lock to determine what the best settings of the aforementioned parameters are.
Quote:

As Rana asked me to in the last meeting, I dug through the elogs to determine what had become of the previous autolockers. I stumbled upon this elog by Rana from before Gautam cleaned up the medm screen. Out of curiosity, I ran the autolocker script using the instructions in Rana's elog. I did this a total of 5 times and could lock the PMC 3 times fairly quickly. I attempted to decipher the details of the code but did not make much headway owing to my unfamiliarity with the language. From what I could make out from the medm screen while the autolocker was running, it appeared to be the same method as that in this elog. I will take a look at it again tomorrow. However, I intend to spend most of tomorrow working on preprocessing the data, developing the CNN script and then the simulation. 

Quote:
 
  1.  I shall also begin working on a script to autolock the PMC based on what Rana showed me on Monday. I will also take a look at the the contents of this elog and try to pick up from there. I hope to make significant progress by the next lab meeting.
  14731   Sun Jul 7 17:54:34 2019 MilindUpdateComputer Scripts / ProgramsPMC autolocker

I modified the autolocker code I wrote to read from a .yaml configuration file instead of commandline arguements (that option still exists if one wishes to override what the .yaml file contains). I have pushed the code to github. I started reading about MCMC and will put up details of the remaining part of the work ASAP.

Quote:
 

P.P.S.  He also said that it would not do to have command line arguments as the main source from which parameters are procured and that .yml files ought to be used instead. I will make that change asap.

  10913   Fri Jan 16 18:09:09 2015 JenneUpdatePSLPMC autolocker not running?

Have we been running the PMC autolocker lately?  I can't remember, and I also can't find where it might be running.  It's not on megatron, either in the crontab or Q's new /etc/init place.  It's also not on op340m. 

Anyhow, what prompted this was that the PMC transmission has been incredibly fuzzy today.  On the StripTool it looks like it was fine until about -7 hours ago, when it lost lock.  Then Diego relocked it around -3 hours ago, and it's been fuzzy ever since. It was unlocked again for about 15 minutes about 45 minutes ago, and when I relocked it, it was even more fuzzy.

The FSS slow is almost exactly zero, the PMC's PZT is not at the edge of the range, the FSS PC drive RMS has been both high and low, and the PMC fuzz level has just been consistently high.  I was checking the parameters in the PMC phase shifter screen, and looked up the autolocker to see what the nominial values are supposed to be. 

For the RFADJ value, the autolocker sets it to 2.0, and after it locks increases it up to 4.5.  I found the value at 2.0, and the autolocker isn't running, which made me wonder if the autolocker died sometime after it set the value low, but before it could detect lock and reset the value to high.  (Actually, after lock it sets the value to whatever is in the channel C1:PSL-STAT_PMC_NOM_RF_ADJ, which is 4.5).

Anyhow, I manually set the RFADJ value to 4.5, and the PMC transmission immediately improved. 

 

EDIT, 8pm, JCD:  Rana reminded me that he attached a screenshot back on 30Dec2014 (http://nodus.ligo.caltech.edu:8080/40m/10849), which I had ignored earlier because the parameters weren't written in text.  My bad.  Anyhow, after the New Year's tune-up, the RFADJ should be 6.0.  I have set it so, and also changed the C1:PSL-STAT_PMC_NOM_RF_ADJ chan to be 6.0.

Attachment 1: PMCfuzz.pdf
PMCfuzz.pdf
  3501   Wed Sep 1 07:52:27 2010 AlbertoConfigurationElectronicsPMC board unplugged, turned on Sorensen switches on 1Y1 rack

Today I put the FSS frequency box back into the 1Y1 rack.

To power it on, I turned on the 24V and 15V Sorensen switches in the same rack.

The PMC crystal board in the same rack should not be affected (it runs with 10V), but, to make sure it was not powered, I disconnected it from its crate. Since the board was disconnected from the EOM for the PSL table's upgrade, I wanted to avoid having the RF output floating.

We just have to remember to plug it back in, when we need it again.

  3504   Wed Sep 1 08:40:28 2010 AlbertoConfigurationElectronicsPMC board unplugged, turned on Sorensen switches on 1Y1 rack

Quote:

Today I put the FSS frequency box back into the 1Y1 rack.

To power it on, I turned on the 24V and 15V Sorensen switches in the same rack.

The PMC crystal board in the same rack should not be affected (it runs with 10V), but, to make sure it was not powered, I disconnected it from its crate. Since the board was disconnected from the EOM for the PSL table's upgrade, I wanted to avoid having the RF output floating.

We just have to remember to plug it back in, when we need it again.

 I just turned on the other Sorensen's too in 1Y1.

  7778   Mon Dec 3 17:04:12 2012 AyakaUpdatePSLPMC calibration for MC_F calibration

In order to calibrate MC_F signal, I need to know the calibration value from thorlab's PZT driver to laser frequency.
The calibration value should be ~ 15MHz/V (the PZT driver has 15 gain, and the laser has the calibration value of ~ 1MHz/V according to the laser spec sheet), but I want to confirm it.
This can be measured by sweeping the input voltage of the PZT driver and see the transmission signal from unlocked PMC.
 

1. Response of PMC transmission when the signal is inputted to laser PZT

I inputted 0.2 Hz triangular wave with 5Vamp and 2.5V offset into the PZT driver and see the transmission signal from PMC. After the PZT driver and before the laser, there is an analog low pass filter but its cut off frequency is 1 Hz so I did not take it into consideration. 
DSC_4955.JPGsweep_PZTdriver.png(TEK00000.CSV, TEK00001.CSV in the zip file)

I could not the side-band resonances. I guess it was because the generated signal is not big enough (but still the maximum range of the signal generator.)
Therefore, in order to calibrate the input voltage to the frequency, I need to know finesse or FWHM frequency.
 

2. Responce of PMC transmission when the voltage of PZT on the PMC is swept

In order to measure the finesse and FWHM frequency, I also swept the PMC PZT voltage with the DC offset slider at the FSS.adl and tried to measure the finesse of PMC. (reference: elog #904)
PMC_PZT_FSR.pdftrans_fit.png(PMC-PZTcal_121203.xml in the zip file)

The result of fitting:

V_FSR (the PZT voltage difference between the 2 resonances) ~ 63 +/- 7 V (= 731MHz (given))
V_FWHM (the PZT voltage to sweep FWHM) ~  0.32 +/- 0.04 V (~ 3.7 MHz)
Finesse ~ 200 +/- 30

However, this finesse value is much smaller than the value on the Wiki, 800. (Manasa showed me.)
V_FSR is comparable to the result Rana got at the referenced elog. But I am not sure about the V_FWHM because it is hard to figure out how large the PZT voltage changed from the template file (PMC-PZTcal.xml).
Are those mode wrong? But if so, where is the correct mode resonances? I think they should be visible...
 

3. Calibration value 

When I know the FWHM frequency, I can calibrate the input on the PZT driver into laser frequency.

The results are:

if I take the finesse of 800 and FSR of 731 MHz (the values on the Wiki): ~5.0 MHz/V
if I take the finesse of 200 and FSR of 731 MHz (the measured value): ~20.0 MHz/V

Actually, the measured value is closer to the value calculated from the spec sheet.

Hmm... Does anyone find falses in my measurement?
If not, the finesse can be 4 times smaller than the value which was 5 years ago?

Attachment 5: PMC-PZTcal_121203.zip
  7779   Tue Dec 4 01:43:37 2012 ranaUpdatePSLPMC calibration for MC_F calibration

  If you can't find the PMC sidebands in the transmission, its because the SNR is too small.

It may be a better idea to look at the PMC error signal, since the DC signal there is suppressed by the demodulation.

  7782   Tue Dec 4 11:30:36 2012 ZachUpdatePSLPMC calibration for MC_F calibration

In order to have less unknown, you can calibrate the PMC PZT separately. Lock the PMC and take a transfer function from either the NPRO PZT input or the FSS AOM VCO input to the PMC control signal. The VCO is better, since the calibration should be much better known, but I am not sure what the current setup of the 40m PSL is, so I don't know if the FSS is normally locked.

Since you know the NPRO PZT or VCO actuation coefficients, you can assume the PMC loop (where the OL gain is high enough) is correcting for the frequency fluctuations. So, simply multiply the known coefficient by the transfer function to get the PMC PZT gain.

Then, you can re-do your PMC PZT sweep measurement and be confident of the calibration. The FSR must be right, so you can get the finesse with confidence.

Quote:

Hmm... Does anyone find falses in my measurement?
If not, the finesse can be 4 times smaller than the value which was 5 years ago?

 

  7823   Thu Dec 13 17:24:53 2012 AyakaUpdatePSLPMC calibration for MC_F calibration

 I calibrated MC_F signal into Hz/rtHz unit using the transfer function from MC_F to PMC feedback signal.

Here is the diagram:
  MC-PMCservo.jpg

n_mcf is MC_F signal we can get at dtt. I measured n_pmc/n'_mcf using SR.

TF_mcf-pmc.png

Other information I used:

G_out = 2.49/123.49 (see the document D980352-E01-C)

Fout has 1 pole at 10 Hz (see the document D980352-E01-C)

A_pzt = 371e+6/63 [Hz/V] (see elog)

F_wt has 1 pole at 100 Hz and 1 zero at 10 Hz.

Then, calibration transfer function of H is fitted as 1e+9/f [Hz/V]:

H.png

Then, the calibrated spectrum of MC_F is below:

 MCF_calib.pdf

This calibration have about 20 % error.
Compared to the spectrum in Jenne's paper (elog), above 20 Hz it seems to be laser frequency noise. But now we have extra unknown noise below 10 Hz.

Note: calibration value of laser's PZT is ~ 1MHz/V. This is reasonable compared to the data sheet of the laser. (This is calculated by combining result of H and transfer function of the circuit box1 and FSS.)

 laser.png

Attachment 6: calib.zip
  304   Sat Feb 9 13:05:48 2008 JohnSummaryIOOPMC camera/ HEPA
I replaced the Gig-E camera on the PMC trans beam. The PZT was close to railing and I wanted to adjust it. I just did a quick job, there is a little scattered light on the image. If Joe is finished with the Gig-E I'll take another look at it.

The HEPA in the PSL table was turned off for some reason. I turned it back on.
ELOG V3.1.3-