40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 168 of 341  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  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.
  104   Thu Nov 15 04:18:11 2007 JohnSummaryPSLPMC cavity pole measurements
In connection with our work on the ISS I attempted to measure the PMC cavity pole.

I swept the PMC PZT and looked at the transmission through the cavity on the ISS Monitor diode (which is now back on the table, feel free to remove it again tomorrow).

To avoid thermal effects I reduced the laser power using the half wave plate at the laser ouput (rotated from 6 deg to 340deg).

I swept the PZT using the triangle wave command "trianglewave C1: PSL-PMC_RAMP -3.5 3.3 20 200". I noticed that the functional form of the resonances deteriorated over the duration of the excitation. Each sweep was able to capture just over one FSR. The resonances were a little close to the 'points' of the triangle wave for my liking although I don't think PZT hysteresis was a big factor.

Looking at the data the peaks are not of uniform width across a sweep or between consecutive sweeps. Hence any results from this mesurement are not particularly useful. I can't be sure if this was due to misalignments, thermal effects, higher order mode content or some other affect.

Rob suggests sweeping the laser frequency using the NPRO PZT instead.
Attachment 1: Peaks.jpg
Peaks.jpg
  15093   Wed Dec 11 15:01:57 2019 JonSummaryPSLPMC cavity ringdown measurement

[Jon, Yehonathan]

We carried out a set of cavity ringdown measurements of the PMC. The 1/e decay time scale is found to be 35.2 +/- 2.4 (systematic) μs. The statistical error is negligible compared to the systematic error, which is taken as the maximum absolute deviation of any measurement from the average value.

To make the measurement, we injected the first order deflection beam of an 80 MHz AOM, then extinguished it quickly by cutting the voltage offset to the AOM driver provided by an RF function generator. A 100 MHz oscilloscope configured to trigger on the falling voltage offset was used to sample the cavity in transmission as sensed by a PDA55. We found the detector noise of the DC-coupled output of the 35.5 MHz REFL PD to be too high for a reflection-side measurement.

Further loss analysis is forthcoming.

Attachment 1: IMG_0101.jpg
IMG_0101.jpg
  15096   Thu Dec 12 19:20:43 2019 YehonathanUpdatePSLPMC cavity ringdown measurement

{Yehonathan, Rana, Jon}

To check whether we laser is being shut fast enough for the ringdown measurement we put a PD55 in the path that leads to the beat note setup. The beam is picked off from the back steering mirror after AOM and before the PMC.

@Shruti the PD is now blocking the beam to your setup.

As before, we drive the AOM to deflect the beam. The deflected beam is coupled to the PMC cavity. We lock the PMC and then shut the beam by turning off the output of the function generator that provides voltage to the AOM driver.

We measure the transmitted light of the PMC together with the light that is picked off before the PMC. In Attachment 1, the purple trace is the PMC transmission, the green trace is the peaked-off beam and the yellow trace is the function generator signal.

Rana was pointing out that the PDs, the function generator and the scope were not carefully impedance matched, which could lead to erroneous measurements. He also mentioned that the backscattered beam was too bright which might indicate that the PMC is oscillating. To remedy this we lowered the gain of the PMC lock to ~8.

We repeat the measurement after setting all the components to 50ohm (attachment 2). We then realize that the BNC T junction connected on the function generator is splitting the signal between the 50ohm AOM driver and 1Mohm oscilloscope channel which causes distortions as can be seen. We remove the T junction and get a much cleaner measurement (see next elog).

 

It seems like either the shutting speed or the PDs are only slightly faster than the PMC. I also check the AOM driver RF output fall time doing the same kind of measurement (attachment 3).

We suspect the PDs' bandwidth is to blame (although they are quoted to have 10MHz bandwidth).

In any case, this is fast enough for the IMC and arm cavities whose lifetime should be much longer than the PMC.

I will post an elog with some numbers tomorrow.

Attachment 1: IMG_0105.jpeg
IMG_0105.jpeg
Attachment 2: TEK00001.PNG
TEK00001.PNG
Attachment 3: 20191212_151642.jpg
20191212_151642.jpg
  15097   Fri Dec 13 12:28:43 2019 YehonathanUpdatePSLPMC cavity ringdown measurement

I grab the data we recorded yesterday from the scope and plot it in normalized units (remove noise level and divide by maximum). See attachment.

It can be seen that the measured ringdown time is ~ 17us while the shut-off time is ~12us.

I plan to model the PD+AOM as a lowpass filter with an RC time constant of 12us and undo its filtering action on the PMC trans ringdown measurement to get the actual ringdown time.

Is this acceptable?

 

Attachment 1: Ringdown_InitialProcess.pdf
Ringdown_InitialProcess.pdf
  15102   Tue Dec 17 20:45:30 2019 ranaUpdatePSLPMC cavity ringdown measurement

idk - I'm recently worried about the 'thermal self locking' issue we discussed. I think you should try to measure the linewidth by scanning (with low input power) and also measure the TF directly by modulating the power via the AOM and taking the ratio of input/output with the PDA55s. I'm curious to see if the ringdown is different for low and high powers

Quote:

I plan to model the PD+AOM as a lowpass filter with an RC time constant of 12us and undo its filtering action on the PMC trans ringdown measurement to get the actual ringdown time.

Is this acceptable?

This is an ole SURF report on thermal self-locking that may be of use (I haven't read it or checked it for errors, but Royal was pretty good analytically, so its worth looking at)

  15105   Fri Dec 27 15:01:02 2019 YehonathanUpdatePSLPMC cavity ringdown measurement

I measured PMC ringdowns for several input powers. I change the input power by changing the DC voltage to the AOM.

First, I raise the DC voltage to the AOM from 0V and observe the signal on the picked off PD. I see that at around 0.6V the signal stops rising. The signal on the PD is around 4V at that point so it is not saturated.

Up until now, we provided 1.5V to the AOM, which means it was saturated.

I measured ringdowns at AOM voltages of 0.05, 0.1, 0.3, 0.5, 1 volt by shutting off the DC voltage to the AOM and measuring the signal at the PMC transmission PD and the picked off PD simultaneously for reference.

Attachment 1 shows the reference measurement for different AOM voltages. For low AOM DC voltages, the response of the AOM+PD is slower.

Attachment 2 shows the PMC transmission PD measurements which barely change as a function of AOM voltage but shows the same trend. I believe that if the AOM+PD response was much faster there would be no observable difference between those measurements.

Attachment 3 shows PMC transmissions and references for AOM voltages 0.05V and 1V. It seems like for low AOM voltages we are barely fast enough to measure the PMC ringdown.

I fitted the 0.3V ringdown and reference to a sum of two exponentials (Attachment 4).

The fitting function is explicitly a * nm.exp(-x/b) +c* nm.exp(-x/d) +e

For the PMC transmission I get:

a = 0.21
b = 3.64 (us)
c = 0.69, 
d = 39.62 (us)
e = 2.0e-04

For the reference measurement:

a = 0.34
b = 4.97 (us)
c = 0.58
d= 31.22 (us)
e = 1.11e-03

I am still not able to do deconvolution of the ref from the measurement reliably. I think we should do a network analyzer measurement.

Shruti, the PD is again in your beam path.

Attachment 1: PDAOMResponse.pdf
PDAOMResponse.pdf
Attachment 2: PMCTransmission.pdf
PMCTransmission.pdf
Attachment 3: RingdownsAndRefs.pdf
RingdownsAndRefs.pdf
Attachment 4: TwoExponentialFitAOM0.3V.pdf
TwoExponentialFitAOM0.3V.pdf
  15107   Tue Dec 31 03:03:02 2019 gautamUpdatePSLPMC cavity ringdown measurement

When I was looking at this, the AOM shutdown time was measured to be ~120 ns, and while I wasn't able to do a ringdown measurement with the PMC (it'd just stay locked because at the time i was using the zeroth order beam), the PMC transmission decayed in <200 ns. 

  15098   Mon Dec 16 18:19:42 2019 shrutiUpdatePSLPMC cavity ringdown measurement : beat-note disruption

I have removed the PD55 + ND filter attached to it (see Attachment) and placed it next to the oscilloscope, after disconnecting its output and power supply. The post is still in place.

I did see the beat after that.

Quote:

{Yehonathan, Rana, Jon}

To check whether we laser is being shut fast enough for the ringdown measurement we put a PD55 in the path that leads to the beat note setup. The beam is picked off from the back steering mirror after AOM and before the PMC.

@Shruti the PD is now blocking the beam to your setup.

 

Attachment 1: IMG_0040.jpg
IMG_0040.jpg
  12939   Tue Apr 11 00:38:37 2017 gautamUpdatePSLPMC demod moved off servo board

As discussed at the Wednesday meeting last week, I tried moving the demodulation of the PMC error signal off the PMC servo board, by using some minicircuits components. This is just a quick summary elog, more details to follow tomorrow.

  • I used the Mini Circuits ZAD-6+. This is a level 7 mixer, and the LO board puts out ~16dBm, so I replaced the existing 3dB attenuator between the LO board and the input to the PMC servo board with a 9dB attenuator.
  • On the RF side, I retained the 35.5 MHz bandpass filter on the PD input.
  • On the IF output, I used an in-line 50ohm terminator in series with a minicircuits BLP1.9+ low pass filter
  • The mixer output was routed to the FP1 test input of the servo board
  • After some twiddling with the demod phase MEDM screen, I was able to lock the PMC. I've not done a thorough characterization of the loop with the current configuration, this will be done tomorrow. But the PMC and IMC have been stably locked for the last couple of hours...

During the course of this work, I noticed that there was a 35.5MHz line (at ~-55dBm) in the 4-pin LEMO DAQ outputs even when all other inputs to the servo board were terminated. So it seems like this pickup is not coming from the RFPD or demod path. The LO board has a shield enclosure similar to what we have on the LSC demod boards, but perhaps this shield does not enclose the full RF path, and there is some residual pickup between the two cards in close proximity in the Eurocrate?

On the bright side, with this demod setup, the higher harmonic peaks seem to be significantly suppressed.

In particular, the 3x35.5 MHz peak which was very prominent when I looked at these spectra with the nominal demod setup, seems to be much suppressed. 

I'm leaving the PMC servo in this configuration (off servo board demodulation using minicircuits parts) overnight.

Attachment 1: PMC_Ctrl_spec.pdf
PMC_Ctrl_spec.pdf
  12940   Wed Apr 12 00:36:53 2017 gautamUpdatePSLPMC demod moved off servo board

Here is a more detailed comparison of the spectra of the signals at the front panel DAQ LEMO output, measured with the Agilent analyzer. I've left the scale linear, it looks like when the demodulation is done on the servo board, the 1x, 3x and 5x harmonics of the 35.5MHz modulation are clearly visible. I also plut in a plot of the spectra when both the PD and LO inputs to the servo board are terminated (and so the PMC is unlocked), but with the HV In and OUT of the servo board still connected. In this case, the higher harmonics vanish, but a 35.5MHz peak of ~-50dBm remains. Since this is present with no input to the servo board, this must be direct pickup from the nearby LO board? 

In any case, it looks like many of the harmonics that are present with the nominal demod setup either vanish or are much more suppressed when the error signal demodulation is done off the servo board yes.


Further down the signal chain, I had noticed sometime last week that the ADC signals for the PMC DAQ channels I set up seemed to saturate around 4000 counts. Rana mentioned that the ADC interface box with LEMO connectors on the front is powered with +/-5V. Valera and co. had simply increased the suppy voltage sometime ago to get around this problem, so I did something similar, and increased the supply voltage to +/- 15V. I then confirmed that the ADC doesn't get saturated by driving the input with a +/-5V signal. So now the amplified AD620 signals from the PMC servo board are better matched to the ADC range. 

Here is an uncalibrated spectrum (taken with IMC locked), compared to the current ADC noise and signal levels before the AD620s were given gain.

I now need to think a little about what exactly the control scheme would be if the PMC is used as a reference for the IMC over some frequency range...

 

Attachment 1: PMC_digitalSpec.pdf
PMC_digitalSpec.pdf
Attachment 2: PMC_DAQ_spectra.pdf
PMC_DAQ_spectra.pdf
  15143   Wed Jan 22 20:12:36 2020 gautamUpdatePSLPMC demodulator electrical characterization

Summary:

The mixer + LPF combo used to demodulate the PMC PDH error signal seems to work as advertised.

Details:

Measurement setup --- Attachment #1. The IF signal was monitored using the scope in High-Z mode.

Results --- Attachment #2.

So the next step is to characterize the RF transimpedance of the PMC RFPD.

Attachment 1: demodChar.pdf
demodChar.pdf
Attachment 2: mixerChar.pdf
mixerChar.pdf
ELOG V3.1.3-