40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 40m Log, Page 165 of 339 Not logged in
ID Date Author Type Category Subject
10353   Fri Aug 8 14:42:41 2014 AkhilUpdateGeneralPID loop Design for beat note stabilization

The attached in a zip file are the Simulink feedback loop models for the FOL for both X and Y ends. The controller PID values are estimated by setting a temperature count reference point to 5344, which corresponds to 100 MHz frequency.  The plant transfer function is as calculated in my previous elogs.

We were not  able to test the PID loop , with the green laser by PZT actuation because of the misalignment of the arms and non-existence of the beat note since last few days. However, we have a complete idea of the design and PID parameters that will be used for the FOL with infrared laser. So we decided that it would be better to test the loop by temperature actuation after the fiber optics is installed and the coupling of infrared laser into the fiber is complete. As of now, we have planned to place the FOL box inside so that it can be used to obtain the green laser beat note on the StripTool graphs.

Attachment 1: PID.zip
3932   Tue Nov 16 12:47:30 2010 AidanUpdateGreen LockingPID loop but no green

The PID loop is ready to be run on the green beat note but, since the tanks are open, there is no green transmission from the end getting to the PSL table. Nevertheless, here's the screen for the PID loop. The loop script is still in my directory /cvs/cds/caltech/users/abrooks/GRNXSlowServo

The medm screen is attached. It shows the current beat note frequency in MHz ()

In c1auxey/ETMYaux.db I added a couple of channels. These are all displayed on the MEDM screen. I added them to autoBurt.req as well.

• C1:LSC-EX_GRNLSR_TEMP_NOM: the zero-volt setpoint temperature of the end laser (as set on the front panel of the Mephisto controller). This must be entered manually in EPICS as there is no way to read it remotely. [Sad Face]
• C1:LSC-EX_GRNLSR_TEMP_CALC: the sum of the zero-volt set point temperature and the offset temperature set by the input voltage from C1:LSC-EX_GREENLASER_TEMP

I rebooted c1auxey to get these to work.

Once we get the green beat back again, the PID loop should servo on the end laser temperature to drive the Beat Frequency to the Frequency Setpoint, C1:LSC-EX_GRN_PID_SETPT, which can be set by the pink slider.

### RA: All MEDM screens must be in the proper MEDM directory!! Also, all perl scripts must have a .pl extension!!! Also, all scripts must be in the scripts directory even if they are in development!!! And all scripts should use 'env' rather than have absolute pathnames for the location of perl, csh, tcsh, python, etc.

3934   Tue Nov 16 16:00:26 2010 AidanUpdateGreen LockingPID loop but no green

 Quote: RA: All MEDM screens must be in the proper MEDM directory!! Also, all perl scripts must have a .pl extension!!! Also, all scripts must be in the scripts directory even if they are in development!!! And all scripts should use 'env' rather than have absolute pathnames for the location of perl, csh, tcsh, python, etc.

That's not unreasonable. But if we try

grep "perl" /cvs/cds/rtcds/caltech/c1/scripts/*/*

you can see that we've got a fair amount of housekeeping to attend to. We might want to think about tidying up the scripts directory as part of the cds upgrade.

13887   Thu May 24 15:18:12 2018 KiraUpdatePEMPID loop restarted

Rana said that it wasn't necessary to gather more data on the temperature fluctuations so I have reconnected the heater circuit and restarted the PID loop with the can on the seismometer.

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

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

3908   Fri Nov 12 12:06:11 2010 AidanConfigurationGreen LockingPID script working - now it needs to be tuned

I've set up a PID script that senses the EX-PSL Green Beat note (from the frequency counter) and actuates on the temperature of the end laser to drive the beat note to a given setpoint.

• I've added the necessary EPICS channels to c1iscaux and rebooted it so that the channels are live. They are listed in a new database file slow_grnx_pid.db
• This database was added to the list of those loaded by startup.cmd.
• The PID script, GRNXSlowServo, is just a modified version of FSSSlowServo.
• The version I've been running is currently in /cvs/cds/caltech/users/abrooks/.
• There's also an MEDM screen in this directoy, C1LSC_EX_GRN_SLOW.adl, there that shows the PID settings.

Right now the script only passes the initial sanities checks, that is:

1. It runs.
2. You can enable/disable it without any errors and it starts actuating.

The settings all need to be tuned up - e.g. maximum_increment, hard_stops, time_step, PID constants.

Additionally, the units in the whole thing are pretty useless - some of the channels are in VOLTS, others in WATTS. I'd like to change all these to be in Hz.

• grecord(ao,"C1:LSC-EX_GRN_SLOWKD")
• grecord(ao,"C1:LSC-EX_GRN_SLOWKP")
• grecord(ao,"C1:LSC-EX_GRN_SLOWKI")
• grecord(ao,"C1:LSC-EX_GRN_PID_SETPT")
• grecord(ao,"C1:LSC-EX_GRN_TIMEOUT")
• grecord(stringin,"C1:LSC-EX_GRN_SLOWVERSION")
• grecord(bi,"C1:LSC-EX_GRN_SLOWLOOP")
• grecord(bi,"C1:LSC-EX_GRN_DEBUG")
• grecord(bi,"C1:LSC-EX_GRN_SLOWBEAT")

Attachment 1: Screen_shot_2010-11-12_at_12.05.01_PM.png
13718   Thu Mar 29 17:14:42 2018 KiraUpdatePEMPID test

[Kira, Gautam]

We closed the loop today and implemented the PID script. I have attached the StripTool graph for an integral value of 0.5 and proportional value of 20. We had some issues getting it to work properly and it would oscillate between some low values of the control voltage. The set point here was -3.20, which corresponds to about a 20 degree increase in temperature. The next step would be to find which values of Kp, Ki, and Kd would work in this case and low pass filter the signal from the temperature sensor, and also create an MEDM screen for easier PID control.

Attachment 1: PID_test.png
13722   Fri Mar 30 06:16:45 2018 ranaUpdatePEMPID test

Can't really figure out what this plot means. We need to see the sensor (in units of deg C) and the control signal (in heating power (W)). The plot should show a few step responses with the PID loop on, so that we can see the loop response time. Please zoom in on the axes so that we can see what's happening.

 Quote: [Kira, Gautam] We closed the loop today and implemented the PID script. I have attached the StripTool graph for an integral value of 0.5 and proportional value of 20. We had some issues getting it to work properly and it would oscillate between some low values of the control voltage. The set point here was -3.20, which corresponds to about a 20 degree increase in temperature. The next step would be to find which values of Kp, Ki, and Kd would work in this case and low pass filter the signal from the temperature sensor, and also create an MEDM screen for easier PID control.

13723   Fri Mar 30 16:10:46 2018 KiraUpdatePEMPID test

I created two new channels today, C1:PEM-SEIS_EX_TEMP_MON_CELCIUS, which turns the output voltage signal into degrees C, and C1:PEM-SEIS_EX_TEMP_CTRL_WATTS, which takes the input voltage from the DAC and turns it into a value of watts. I'm trying to stabilize the temperature at 35 degrees, but it's taking a lot longer than expected. Perhaps we'll need to use different values for P and I and decrease the noise in the sensor, since right now there's about a 10 degree variation between the highest and lowest values.

13726   Wed Apr 4 16:23:10 2018 KiraUpdatePEMPID test

I did a step response for the loop from 35 degrees to 40 degrees. The PID is not properly tuned, so the signal oscillates. In the graph, the blue curve is the temperature of the can in celcius and the green curve is the heating power in watts. The x-axis is in minutes. Before, the signal was too noisy to do a proper step response, so I placed a 3.3 microF capacitor in parallel with the resistor in my temperature sensor circuit (I'll draw and attach this updated version). This created a 5 Hz low pass filter and the signal is now pretty clean.

-----

I also added in new Epics channels so that we could log the data using Data Viewer. The channels I added were C1:PEM-SEIS_EX_TEMP_MON_CELCIUS and C1:PEM-SEIS_EX_TEMP_CTRL_WATTS. I used 13023 as a guide on how to do this.

Update: the channels work and show data in Data Viewer

-----

Edit: I've attached a photo of the circuit with the capacitor indicated. It is in parallel with the resistor below it. I've attached an updated circuit diagram as well.

Attachment 1: step_response.png
Attachment 2: capacitor.jpg
Attachment 3: IMG_20180412_120427.jpg
13618   Wed Feb 7 17:01:25 2018 gautamUpdatePEMPID test plan

[kira, gautam]

We did a survey of the lab today to figure out some of the logistics for the PID control test for the seismometer can. Kira will upload sketches/photos from our survey. Kira tells me we need

• +/- 15V for the temperature sensors
• +/- 20V, 5A for heater circuit (to be confirmed by Kira after looking at voltage regulator datasheet for dropout voltage)
• 2 ADC channels for temperature sensing (one inside can and one outside)
• 1 DAC channel for controlling MOSFET

There are no DAC channels available in the c1ioo rack. In fact, there is a misleading SCSI cable labelled "c1ioo DAC0" that comes into the rack 1X3 - tracing it back to its other end, it goes into the c1ioo expansion chassis - but there are no DAC cards in there, and so this cable is not actually transporting any signals!

So I recommend moving the whole setup to the X end (which is the can's real home anyways). We plan to set it up without the seismometer inside for a start, to make sure we don't accidentally fry it. We have sufficient ADC and DAC channels available there (see Attachments #1 and #2, we also checked hardware), and also Sorensens to power the heater circuit / temperature sensing circuit. Do we want to hook up the Heater part of this setup to the Sorensens, which also power everything else in the rack? Or do we want to use the old RefCav heater power supply instead, to keep this high-current draw path isolated from the rest of our electronics?

### If this looks okay (after pics are uploaded), we will implement these changes (hardware + software) tomorrow.

-----

I have attached the sketch of the whole system (attachment 3) with all the connections and inputs that we will need. Attachment 4 is the rack with the ADC and DAC channels labeled. Attachment 5 is the space where we could set up the can and have the wires go over the top and to the rack.

Attachment 2: DAC_EX.png
Attachment 3: IMG_20180207_170628.jpg
Attachment 5: IMG_20180207_165833.jpg
13619   Wed Feb 7 19:14:19 2018 ranaUpdatePEMPID test plan
1. The heater circuit should get its own dedicated supply.
2. We do not want to ever use the old Ref Cav heater for anything. Its unreliable and noisy.
3. Steve should update all the sticky labels on all the power supplies in the lab to indicate what voltage they should be set at. Even if the label is correct, the date should be updated.
13624   Thu Feb 8 12:24:37 2018 KiraUpdatePEMPID test plan

Some points before we can set up the can:

1. Cable length and type
• For the DAC, we can use the LEMO outputs and change it to BNC, then have a long BNC cable running over the top of the lab and to the can
• ADC is also LEMO, which we can convert to BNC and have a cable run from that to the temperature sensors
• Sorensens use plain cables, so we need to find ones that can take a few amps of current and have them be long enough to reach the can and temperature sensors
2. Making sure that there is enough space for the can
• Can measures about 59 cm in diameter, which does fit in the space we chose
3. Finding Sorensens that work and can provide +/-24V to the heater circuit (since Rana said we want the heater to have its own supply)
• Found two Sorensens, but only one works for our purpose (update: found a second one that works)
• The other can only proviide up to 20V before shorting and has been labeled
• Grounding (see point 5) - we want to have these power supplies be independent, but we must still specify a ground
• There is exactly enough space to fit in the two Sorensens below the ones that are currently there
4. DIN fuses for 15V and 24V
• 15V fuses can be easily installed since we don't need a very high current for the temperature sensors
• the 24V fuses seem to be able to handle 6.3A according to the datasheet, but it only says 4V on the fuse itself. Not sure if this is the wrong darasheet...
5. Connecting the crcuit to the DAC and what connectors to use
• Using the rightmost DAC because there's less important things connected to it, and use the LEMO conncectors to provide the input
• Connect the grounds of the DAC and the new Sorensens that we're going to install to the grounds of the rest of the Sorensens
• *confirm that this setup will work and if not find an alternative
6. Which channels to use for the ADC
• channels 29, 30, 31 are available, so we can use any two of those (one for each sensor)

Also, I need to eventually remake the connections on my circuit board because they are all currently test points. I also need to find a box for the heater circuit and figure out what to do with the MOSFET and heat sink for it. This can either be done before setting everything up, or we can just change it later once we have the final setup for the can ready.

If all of this looks good then we can begin the setup.

gautam:

1. I recommend using a DAC output from the rightmost AI board because (i) only the green steering mirror PZTs are hooked up to it while the other has ETMX suspension channels and (ii) the rightmost AI board has differential receiving from the DAC, and in light of the recent discussions about ground loops, this seems to be the way to go. Outputs 5-8 are currently unused, while outputs 1-4 are used for the EX green input steering mirror control.
2. Converters required:
• 2 pin LEMO to BNC --- 2pcs for each temp sensor.
• Single pin LEMO to BNC --- 1pc for AI board to heater circuit input (readily available)
13626   Thu Feb 8 17:32:44 2018 KiraUpdatePEMPID test plan

[Kira, Steve]

We set up a new rail for the Sorensens (attachment 1) and placed one of them down on this new rail (attachment 2). Unfortunately the older rail that had been used to support the other Sorensens (the top one in attachment 1) is thick and does not allow another one of the Sorensens to slide in between the current ones. So we will have to support all the ones on top with a temporary support, take out the old rail, and then insert the new ones before letting the new bottom rail carry the weight of all of the Sorensens. We will do that tomorrow.

In addition, we have to figure out how to lead all the cables to the can, but there are no holders on the side of the lab to do so. So, we decided that we would have a new one installed on the side shown in attachment 3 so that we wouldn't have to place the wires along the floor.

Also, there has been some space made for the can along with the new insulation. The stuff mounted on the wall was removed and will be reattached tomorrow so that it doesn't get in the way of the can anymore.

Attachment 1: IMG_20180208_171423.jpg
Attachment 2: IMG_20180208_172107.jpg
Attachment 3: IMG_20180208_171853.jpg
Attachment 4: IMG_20180208_171932.jpg
13629   Fri Feb 9 15:29:32 2018 KiraUpdatePEMPID test plan

[Kira, Steve]

We installed and labeled the Sorensens today.

Attachment 1: IMG_20180209_152158.jpg
13634   Thu Feb 15 16:03:57 2018 KiraUpdatePEMPID test plan

I checked channels 6 and 7 on the ADC and they have long wires leading to BNC ends and are currently not being used, so we could probably just attach the temperature sensors to those channels.

13768   Thu Apr 19 11:29:11 2018 ranaUpdatePEMPID tune

Yesterday, I changed the P gain of the PID loop from zero to  +0.1. Seems good so far; will monitor for a couple days to see if we're in the right ballpark. Main issue in the stability may now be that the quantization noise is too big for the temperature sensor. If so, we should consider subtracting off the DC value (with a V ref) and then amplifying before ADC.

Attachment 1: Screen_Shot_2018-04-19_at_11.27.08_AM.png
13780   Mon Apr 23 20:06:35 2018 ranaUpdatePEMPID tune

This shows a step response of the EX seis temp control with K_I = -1 and K_P = -0.1. The time constants for both heatup and cooldown are ~2 hours.

I'm not so sure if the PID code itself makes sense though:

  # The basic finite-difference PID approximation   e[0] = (p-s)   print("Error signal = {}" .format(e[0])) 

  # These are the main equations of the PID Process   u[0] = u[1]   u[0] = u[0] + Kp * (e[0] - e[1])   u[0] = u[0] + Ki * (e[0])   u[0] = u[0] + Kd * (e[0] - 2*e[1] + e[2])

Seems like the Proportional term uses the difference (or derivative) of the error signal. This makes it more likely to pick up some high frequency noise; maybe we should low pass this signal somewhat, or at least implement a running average.

Since we still don't have an out of loop sensor or a PSL room temperature monitor or a particle counter in the frames, I've disabled the PID loop to see how much the can temperature varies with no feedback. Please leave it this way for a few days.

Attachment 1: HeaterTest.png
13735   Fri Apr 6 16:17:20 2018 KiraUpdatePEMPID tuning

I have been trying to tune the PID and have managed to descrease the oscillations without saturating the actuator. I'm going to model the system to calculate the exact values of P, I and D in order to get rid of the oscillations altogether. I was going to record the data using Data Viewer, but there seems to be some issue with that, so I'm using StripTool for now.

Attachment 1: PID_tuning_progress.png
13736   Fri Apr 6 18:28:57 2018 ranaUpdatePEMPID tuning

1. Set P and D gains to zero. We only need slow drift control.
2. Changed names of the python script and .ini file to distinguish it from the FSS stuff. Lives in scripts/PEM/
3. removed debug flag from argParse. To run in non-debug mode you use the "-O" option of python as usual.
4. Fixed the upper/lower limit convention for the heater. Was backwards.
5. Removed the "rail" function that was defined. We can just use numpy.clip since that's already built in.

There is also now a StripTool file in the scripts/PEM directory which has appropriate channel names and scales for PID loop tuning. Use this file!

I'm leaving it running over the weekend with K_I = -0.003. There is a StripTool on rossa which you can watch. The code itself is running on a tmux session on megatron. Let's ONLY run this code there until we're satisfied that things are good.

Update Sun Apr 8 00:40:11 2018: Lowered gain by factors of 3 down to -0.0001 Saturday afternoon. Seems like still oscillating a bit, now with a ~4 hour period. Setting it to -3e-5 now. Usually we have a linear feedback loop, but our actuation voltage actually gets squared (P = I^2 R) before being integrated to produce temperature. Wonder if we should think of linearizing the feedback control signal to make the loop act nicer.

Update Sun Apr 8 21:09:48 2018: Set K_I = -1e-5 earlier today. Seems to have stabilized nearly, but temperature swings are still +/- 1 K. Will need to add some proportional feedback (K_P) to increase the loop bandwidth, but system is at least sort of stable now. Probably should start construction of EY,BS systems now.

Attachment 1: HeaterTest.png
8755   Wed Jun 26 11:45:06 2013 gautamUpdateGeneralPID tuning-Doubling Oven at Y end

Summary

Having established the serial link between the Doubling oven at the Y-end and the Raspberry pi, I wanted to use this interface to collect time-series from the oven after applying a step function in an effort to measure the transfer function of the oven. The idea was that knowing the transfer function of the oven, I could use some simple PID tuning rules like the Ziegler-Nichols rule or put everything in SIMULINK and find the optimal PID gains. However, I am unable to extract the oven transfer function from the time series data collected.

Methodology:

Last night, between 920pm and 940pm I applied a step function to the doubling oven by changing the setpoint of the controller from 35.7 Celsius to 39 Celsius (having checked elog 3203 to get an idea of a 'safe' step to apply). I then used the Pi to collect time series data for 6 minutes, then returned the set-point back to 35.7 Celsius, and took another time-series to make sure things were back to normal. Having gotten the time series data, I attempted to fit it using some exponentials which I derived as follows:

I couldn't think of a way to get the laplace transform of the time-series data collected, so I approximated the oven transfer function as a system with a one simple pole i.e. G(s)=K/(1+Ts), where K and T are parameters that characterise the oven transfer function. I then plugged in the above expression for Y(s) into Mathematica (knowing X(s)=constant/s, and H(s) = 250 + 60/s +25s from the PID gains) and did an inverse laplace transform to find a y(t) with two unknown parameters K and T to which I could fit the time-series data.

Results:

The time-series data collected via the Pi after applying the step was this:

The inverse laplace transform from mathematica yielded the following (formidable!) function (time, the independent variable, is x, and the fitting parameters are a=K and b=T where K and T are as described earlier):

(39*(exp(x*(1/(2*(25*a - b)) - (125*a)/(25*a - b) - sqrt(1 - 500*a+ 56500*a^2 + 240*a*b)/(2*(25*a - b)))) - exp(x*(1/(2*(25*a - b)) - (125*a)/(25*a - b) + sqrt(1 - 500*a + 56500*a^2 + 240*a*b)/(2*(25*a - b)))))*a)/sqrt(1 - 500*a + 56500*a^2 + 240*a*b)

My best attempts to fit this using MATLAB's cftool have given me useless fits:

I tried changing the start-points for the fitting parameters but I didn't get any better fits.

To Do:

1. Explore other fitting options.
2. Try and find a way to Laplace transform the time-series data so I can do the fitting in the s-domain.
3. I have some tweaking to do as far as the python scripts on the pi are concerned.
4. I have to get the current temperature readings onto one of the unused Y-arm EPICS channels, and log that data ~ once every 10 seconds.

Misc Remarks:

1. The time-series data has a 'stepped' appearance because of the resolution of the temperature sensor: it is 0.1 Celsius.
2. The sampling rate of the data-acquisition is limited; right now, I wait for 0.15 seconds after sending the command word to the controller before reading the data. When I set the wait-period any lower than this, I get errors. This has to be investigated more as I feel I should be able to get better sampling with the advertised baudrate of 115200, but in any case, it looks like it is sufficient for our purposes.

10882   Fri Jan 9 10:52:37 2015 SteveUpdateSUSPIT trend plots at the ends

100 and 10 days trends of ETMX and ETMY_SUSPIT.  One can see clearly the earthquaks of Dec.30 and 31 on the 10 day plot. You can not see the two shakes  M3.0 & M4.3 of Jan. 3

The long term plot looks OK , but   the 10 day plot show the problem of ETMX as it was shaken 4 times.

Attachment 1: susPITends.png
15088   Mon Dec 9 21:22:46 2019 shrutiUpdateGeneralPLL / PM measurement of Xend NPRO PZT

### In short:

Using the same setup as before with a LPF changed to have a cutoff of 5 MHz, the PLL was implemented and a TF measurement of the phase modulation was attempted. But, the beatnote drift was too high to get a prolonged phase lock (many times over 5MHz in <5 min).

### Steps undertaken:

1. Normally I would unlock the IMC (Disabling the servo between the 'Filter' and 'Polarity' on the Mode Cleaner Servo Screen), but today I did not have to since Rana had kept it unlocked.

2. Misaligned the ITMX. This is to prevent cavity resonances from returning to the laser

3. Turned up the air on the HEPA at the PSL table to 100% during the measurement

4. Cables were connected as before (diagram shown in attachment of elog 15069)

5. The X end laser NPRO was actuated for the TF measurement using a long cable connected to TO AUX_X LASER PZT

### Thoughts and observations:

- Reading out the error signal after amplification cannot distinguish between a locked loop or one out of its range. The error signal would be very small in both cases.

- Looking at the beat note on an oscilloscope, there also seemed to be an additional amplitude modulation that I had not noticed earlier. Rana suggested that it may have something to do with the pre-mode cleaner and the AOM being driven at 80 MHz

- Even though the TF was attempted, it seemed too noisy, suggesting that the PLL did not seem to work

- Rana also suggested that it may be a better idea to use the PZT of one of the lasers as the VCO for the PLL feedback instead of the Marconi.

 Quote: I worked on the setup up for the phase modulation measurement of the X end NPRO PZT. A previous similar measurement can be found here (12077). The setup was assembled based on the schematic in Attachment1. Mixer used: Level 7, Mini circuits ZP-3+ LPF: up to 1.9MHz Cables exiting the PSL table: 1. LO (Marconi -> Mixer) 2. RF (PSL+X beat note -> Mixer) The cable for this was taken from the Beat Mouth (otherwise connected to the oscilloscope) 3. Ext modulator (SR560 -> Marconi) The long cable labled 'X Green Beat' was used to connect to the PZT (from the network analyzer). Observations: The beat note kept floating between 0 and ~100 MHz The PLL part of the circuit was tested coarsely with the spectrum analyzer function of the Agilent, where the loop was seen to stabilize when the carrier frequency of the Marconi was close to the instantaneous beat frequency.

15101   Tue Dec 17 20:08:09 2019 shrutiUpdateGeneralPLL / PM measurement of Xend NPRO PZT

## 1. Some calculations

For a Unity Gain Frequency (UGF) of 1 kHz, assumed PZT response $K_{VCO}$ of 1 MHz/V, Mixer response $K_{M}$ of 25 mV/$\pi$ rad, the required gain of the amplifier is

$G = 2 \pi \times \text{UGF}/ (K_{VCO} K_M)$

G ~ 0.8

## 2. Progress

- Measured the mixer response

### Measuring mixer response:

- PSL laser temperature was adjusted so that beat frequency was roughly 25 MHz and the amplitude was found to be roughly -30dBm.

- At the RF port instead of the beat signal, a signal of 25 MHz + few kHz at -30 dBm was inputted. The LO was a 25 MHz signal was sent from the Marconi at 7 dBm.

- The mixer output was measured, with setup as in Attachment 1  Figure (A), on an oscilloscope. The slope near the small angle region of the sine curve would be the gain (in V/rad) and was found to be: $K_M \approx 25 \text{ mV}/ \pi$ rad

- Since from the above calculations it seemed like an amplifer gain of 1 should work for the PLL, I rearranged the set up as in Figure (B) of Attachment 1 to actuate the X end NPRO PZT, I adjusted the PSL temperature (slow control) to try and match the frequency to 25 MHz, but couldn't lock the loop. I was monitoring the error signal after amplification (50 ohm output of the SR 560) which showed oscillations when the beat frequency was near 25 MHz and nothing significant otherwise.

- I used a 20 dB attenuator at the amplifier output and saw the beat note oscillate for longer, but maybe because it was a 50 ohm component in a high impedance channel it did not work either (?). I tried other attenuator combinations with no better luck.

- Is there a better location to add the attenuator? Should I pursue amplifying the beat signal instead?

- Also, it seemed like the beat note drift was higher than earlier. Could it be because the PMC was unlocked?

 Quote:

Attachment 1: 20191217.png
15129   Thu Jan 16 19:32:23 2020 shrutiUpdateGeneralPLL / PM measurement of Xend NPRO PZT

With Gautam's help today the PLL managed to be be locked for a few brief moments. Turns out the signal power of the beat was an issue.

What was changed prior to/ during the experiment:

1. The PSL shutter was closed so not light goes into the input mode cleaner.

2. HEPA turned up (will be turned back down to ~30%)

3. AOM driver offset voltage decreased from 1V to ~100 mV (this will be reverted to 1V by the end of today). This increases the beat signal by deflecting the zeroth order beam to create the beat.

4. Output of servo SR 560 sent to the PZT of the X NPRO laser (the cable was disconnected from the pomona box at the X end)

5. The SR560, mixer, LPF and cables required for connections were moved into the PSL enclosure.

6. The error and control signals were hooked up to the oscilloscope where the beat outputs were visible (the setup has been reverted back to the original).

Elog 14687 has a detailed description of the conditions that provide a stable lock. I was told that the PI controller (LB1005) may be a better servo than the SR560, but today it was not used.

1) Parameters during the more successful attempts:

LPF: 5 MHz, Mixer: ZP-3+

Gain set at SR560: varied, but generally 200

Filter at SR560: 1 Hz low pass (single pole? at least by the label)

2) The LO had to be very close (<2 MHz) to the beat frequency in order to achieve a lock for ~30s

gautam edits:

• the error signal for the PLL was being sourced from the 20dB coupled port on the BeatMouth.
• additionally, most of the power in the PSL beam coupled into the fiber was being deflected into the first order beam by team ringdown.
• The Vpp of the mixer output (when using the coupled beat and low PSL beam power) was a paltry 5-10 mVpp .
• I suggested using the direct NF1611 output for this measurement instead of the coupled output (alternatively, use an amp). it's probably also better to use the LB1005 for locking the PLL, long term, this can be set up to be controlled remotely, and a slow PID servo can be used to extend the duration of the lock by servoing either the marconi carrier freq or the EX temp ctrl.
Quote:

## 1. Some calculations

For a Unity Gain Frequency (UGF) of 1 kHz, assumed PZT response $K_{VCO}$ of 1 MHz/V, Mixer response $K_{M}$ of 25 mV/$\pi$ rad, the required gain of the amplifier is

$G = 2 \pi \times \text{UGF}/ (K_{VCO} K_M)$

G ~ 0.8

## 2. Progress

- Measured the mixer response

### Measuring mixer response:

- PSL laser temperature was adjusted so that beat frequency was roughly 25 MHz and the amplitude was found to be roughly -30dBm.

- At the RF port instead of the beat signal, a signal of 25 MHz + few kHz at -30 dBm was inputted. The LO was a 25 MHz signal was sent from the Marconi at 7 dBm.

- The mixer output was measured, with setup as in Attachment 1  Figure (A), on an oscilloscope. The slope near the small angle region of the sine curve would be the gain (in V/rad) and was found to be: $K_M \approx 25 \text{ mV}/ \pi$ rad

- Since from the above calculations it seemed like an amplifer gain of 1 should work for the PLL, I rearranged the set up as in Figure (B) of Attachment 1 to actuate the X end NPRO PZT, I adjusted the PSL temperature (slow control) to try and match the frequency to 25 MHz, but couldn't lock the loop. I was monitoring the error signal after amplification (50 ohm output of the SR 560) which showed oscillations when the beat frequency was near 25 MHz and nothing significant otherwise.

- I used a 20 dB attenuator at the amplifier output and saw the beat note oscillate for longer, but maybe because it was a 50 ohm component in a high impedance channel it did not work either (?). I tried other attenuator combinations with no better luck.

- Is there a better location to add the attenuator? Should I pursue amplifying the beat signal instead?

- Also, it seemed like the beat note drift was higher than earlier. Could it be because the PMC was unlocke

15148   Thu Jan 23 20:08:49 2020 shrutiUpdateGeneralPLL / PM measurement of Xend NPRO PZT

### Setup Update:

- No more SR 560, upgraded to LB1005 P-I controller.  Because: Elog 14687. Schematic of new setup shown in Attachment 1.

- For this, the Marconi was moved to the other (east) side of the PSL table and a power supply was also placed in the enclosure.

I think that the RF power at the mixer in this new configuration is 0 dBm (since the spectrum analyzer read ~ -20 dBm)

### Progress Today:

- Turned up the HEPA to 100%, closed the PSL shutter, misaligned the ITMX, connected the LB1005 to the PZT. [The PZT has been reconnected to the X arm PDH servo, HEPA back to 20-30%]

- Tried to look for the PSL+X beat, but it was not there. Gautam identified the flipmount in the path which sorted it out (eventually), but there was no elog about it.

- After much trial, the loop seemed to lock with PI corner 1 kHz, gain ~2.9 (as read on knob), LFGL set to 90 dB. The beat note looked quite stable on the oscilloscope, but the error signal had an rms of ~100 mV (Rana pointed out that it could be the laser noise) and the lock lasted for ~1 min each time.

The parameters were similar to that in elog 14687. Why do we require such a high PI corner frequency and LFGL?

Attachment 1: Image-1.jpg
15169   Tue Jan 28 19:40:15 2020 shrutiUpdateGeneralPLL / PM measurement of Xend NPRO PZT

Over the past few days, I have been trying to make measurements of the phase modulation transfer function by modulating the X end laser PZT via PLL.

The setup was modified every time during the experiment in the same manner as mentioned in elog 15148.

I could not make the PLL lock for long enough to take a proper TF measurement, resulting in TFs that look like Attachment 1. The next step would be to use the method of a delay line frequency discriminator instead of the PLL.

1. I do not understand why the high PI corner frequency of 1kHz or 3kHz was required to lock.
2. The rms level of the error signal when locked was ~100 mV, which is 25% of the total mixer range (~400 mVpp). Decreasing the gain only caused the loop to go out of lock and did not decrease this noise in the error signal.
3. The setup was also partly inside the PSL enclosure, with the HEPA turned to 100%, which is probably a noisy environment for this measurement. Closing and opening the shutters or any disturbance near the enclosure resulted in movement of the beat note up to 5 MHz.
4. It may have been a better idea to actuate the PSL laser instead of the X NPRO because of its larger range, but would this solve the issue with the noise?
Attachment 1: PMTF.pdf
Attachment 2: BeatSpectrum.pdf
2230   Tue Nov 10 19:21:53 2009 AlbertoUpdateABSLPLL Alignment

I've been trying to lock the PLL for the AbsL Experiment but I can't see the beat (between the auxiliary NPRO and the PSL).

I believe the alignment of the PLL is not good. The Farady Isolator is definitely not perfectly aligned (you can see it from the beam spot after it) but still it should be enough to see something at the PLL PD.

it's probably just that the two beams don't overlap well enough on the photodiode. I'll work on that later on.

I'm leaving the lab now. I left the auxiliary NPRO on but I closed its shutter.

All the flipping mirrors are down.

2576   Mon Feb 8 14:13:03 2010 AlbertoUpdateABSLPLL Characterization

Lately I've been trying to improve the PLL for the AbsL experiment so that it could handle larger frequency steps and thus speed up the cavity scan.

The maximum frequency step that the PLL could handle withouth losing lock is given by the DC gain of the PLL. This is the product of the mixer's gain factor K [rad/V ], of the laser's calibration C [Hz/V] and of the PLL filter DC gain F(0).

I measured these quantities: K=0.226 V/rad; C=8.3e6 Hz/V and F(0)=28.7dB=21.5. The max frequency step should be Delta_f_max = 6.4MHz.

Although in reality the PLL can't handle more than a 10 KHz step. There's probably some other effect that I'm not.

I'm attaching here plots of the PLL Open Loop Gain, of the PLL filter and of a spectra of the error point measured in different circumstances.

I don't have much time to explain here how I took all those measurements. After I fix the problem, I'm going to go go through those details in an elog entry.

Does anyone have any suggestion about what, in principle, might be limiting the frequency step?

I already made sure that both cables going to the mixer (the cable with the beat signal coming from the photodiode and the cable with the LO signal coming from the Marconi) had the same length. Although ideally, for phase locking, I would still need 90 degrees of phase shift between the mixing signals, over the entire frequency range for which I do the cavity scan. By now the 90 degrees are not guaranteed.

Also, I have a boost that adds another 20 dB at DC to the PLL's filter. Although it doesn't change anything. In fact, as said above calculating the frequency step, the PLL should be able to handle 100KHz steps, as I would want the PLL to do.

Attachment 1: 2010-02-08_Old_PDH_Box_Filter_TF_gain_knob_0_Boost_OFF.png
Attachment 2: 2010-02-08_PLL_OLG_gain_knob_0_Boost_OFF.png
Attachment 3: 2010-02-08_PLL_Noise_Budget.png
2581   Tue Feb 9 09:07:06 2010 AlbertoUpdateABSLPLL Characterization

 Quote: Lately I've been trying to improve the PLL for the AbsL experiment so that it could handle larger frequency steps and thus speed up the cavity scan. The maximum frequency step that the PLL could handle withouth losing lock is given by the DC gain of the PLL. This is the product of the mixer's gain factor K [rad/V ], of the laser's calibration C [Hz/V] and of the PLL filter DC gain F(0). I measured these quantities: K=0.226 V/rad; C=8.3e6 Hz/V and F(0)=28.7dB=21.5. The max frequency step should be Delta_f_max = 6.4MHz. Although in reality the PLL can't handle more than a 10 KHz step. There's probably some other effect that I'm not. I'm attaching here plots of the PLL Open Loop Gain, of the PLL filter and of a spectra of the error point measured in different circumstances. I don't have much time to explain here how I took all those measurements. After I fix the problem, I'm going to go go through those details in an elog entry. Does anyone have any suggestion about what, in principle, might be limiting the frequency step? I already made sure that both cables going to the mixer (the cable with the beat signal coming from the photodiode and the cable with the LO signal coming from the Marconi) had the same length. Although ideally, for phase locking, I would still need 90 degrees of phase shift between the mixing signals, over the entire frequency range for which I do the cavity scan. By now the 90 degrees are not guaranteed. Also, I have a boost that adds another 20 dB at DC to the PLL's filter. Although it doesn't change anything. In fact, as said above calculating the frequency step, the PLL should be able to handle 100KHz steps, as I would want the PLL to do.

I might have found the problem with the PLL that was preventing me from scanning the frequencies by 100KHz steps. A dumb flimsy soldering in the circuit was making the PLL unstable.

After I fixed that problem and also after writing a cleverer data acquisition script in Python,  I was able to scan continuosly the range 10-200MHz in about 20min (versus the almost 1.5-2 hrs that I could do previously). I'm attaching the results to this entry.

The 'smears' on the right side of the resonance at ~33MHz, are due to the PSL's sideband. I think I know how to fix that.

As you can see, the problem is that the model for the cavity transmission still does not match very well the data. As a result, the error on the cavity length is too big (~> 10 cm - I'd like to have 1mm).

Anyway, that was only my first attempt of scanning. I'm going to repeat the measurement today too and see if I can come out better. If not, than I have to rethink the model I've been using to fit.

Attachment 1: 2010-02-08_PRCtransmissivity_EntireFreqRange_VsFit.png
2261   Thu Nov 12 18:10:27 2009 AlbertoUpdateABSLPLL Locked

I locked the PLL and made some first measuremtns of the spectrum of the error signal. I'll post them later.

I closed the shutter of the NPRO.

11925   Mon Jan 11 19:01:56 2016 gautamUpdateLSCPLL Marconi Investigation

EDIT 01/12/2016 6PM: I've updated the plots of the in-loop spectra such that they are calibrated throughout the entire domain now. I did so by inferring the closed-loop transfer function (G/(1-G)) from the measured open-loop transfer function (G), and then fitting the inferred TF using vectfit4 (2 poles). The spectra were calibrated by multiplying the measured spectra by the magnitude of the fitted analytic TF at the frequency of interest.

EricQ brought back one of the Marconis that was borrowed by the Cryo lab to the 40m today (it is a 2023B - the Marconi used for all previous measurements in this thread was 2023A). Koji had suggested investigating the frequency noise injected into the PLL by the Marconi, and I spent some time investigating this today. We tried to mimic the measurement setup used for the earlier measurements as closely as possible. One Marconi was used as a signal source, the other as the LO for the PLL loop. All measurements were done with the carrier on the signal Marconi set to 310MHz (since all our previous measurements were done around this value). We synced the two Marconis by means of the "Frequency Standard" BNC connector on the rear panel (having selected the appropriate In/Out configurations digitally first). Two combinations were investigated - with either Marconi as LO and signal source. For each combination, I adjusted the FM gain on the Marconi (D in the plot legends) and the overall control gain on the SR560 (G in the plot legends) such that their product remained approximately constant. I measured the PLL OLG at each pair to make sure the loop shape was the same throughout all trials. Here are the descriptions of the attached plots:

Attachment #1: 2023A as LO, 2023B as source, measured OLGs

Measured OLG for the various combinations of FM gain and SR560 gain tested. The UGF is approximately 30kHz for all combinations - the exceptions being D 1.6MHz, G=1e4 and D=3.2MHz, G=1e4. I took the latter two measurements just because these end up being the limiting values of D for different carrier frequencies on the Marconi.

Attachment #2: 2023A as LO, 2023B as source, measured spectra of control signal (uncalibrated above 30kHz)

I took the spectra down to 2Hz, in two ranges, and these are the stitched versions.

Attachment #3: 2023B as LO, 2023A as source, measured OLGs

Attachment #4: 2023B as LO, 2023A as source, measured spectra of control signal (uncalibrated above 30kHz)

So it appears that there is some difference between the two Marconis? Also, if the frequency noise ASD-frequency product is 10^4 for a healthy NPRO, these plots suggest that we should perhaps operate at a lower value of D than the 3.2MHz/V we have been using thus far?

As a quick trial, I also took quick spectra of the PLL control signals for the PSL+Aux X and PSL+Aux Y beat signals, with the 2023B as the LO (Attachment #5). The other difference is that I have plotted the spectrum down to 1 Hz (they are uncalibrated above 30Hz). The PSL+Y combination actually looks like what I would expect for an NPRO (for example, see page 2 of the datasheet of the Innolight Mephisto) particularly at lower frequencies - not sure what to make of the PSL+X combination. Also, I noticed that the amplitude of the PSL+Y beatnote was going through some large-amplitude (beat-note fluctuates between -8dBm and -20dBm) but low frequency (period ~10mins) oscillations. This has been observed before, not sure why its happening though.

More investigations to be done later tonight.

Attachment 1: 2023ALockedto2023B.pdf
Attachment 2: 2023ALockedto2023B_spectra.pdf
Attachment 3: 2023BLockedto2023A.pdf
Attachment 4: 2023BLockedto2023A_spectra.pdf
Attachment 5: TestSpectra.pdf
Attachment 6: 2016_01_AUXLaser.tar.gz
2338   Wed Nov 25 20:24:49 2009 AlbertoUpdateABSLPLL Open Loop Gain Measured

I measured the open loop gain of the PLL in the AbsL experiment.

I repeated the measurement twice: one with gain knob on the universal PDH box g=3.0; the second measurement with g=6.0

The UGF were 60 KHz and 100 KHz, respectively.

That means that one turn of the knob equals to about +10 dB.

Attachment 1: 2009-09-25_OLgain_g3png.png
Attachment 2: 2009-09-25_OLgain_g6png.png
2342   Fri Nov 27 02:25:26 2009 ranaUpdateABSLPLL Open Loop Gain Measured

 Quote: I measured the open loop gain of the PLL in the AbsL experiment.

Plots don't really make sense. The second one is inherently unstable - and what's g?

15069   Tue Dec 3 22:41:17 2019 shrutiUpdateGeneralPLL for PM measurement

I worked on the setup up for the phase modulation measurement of the X end NPRO PZT. A previous similar measurement can be found here (12077). The setup was assembled based on the schematic in Attachment1.

Mixer used: Level 7, Mini circuits ZP-3+
LPF: up to 1.9MHz

Cables exiting the PSL table:
1. LO (Marconi -> Mixer)
2. RF (PSL+X beat note -> Mixer) The cable for this was taken from the Beat Mouth (otherwise connected to the oscilloscope)
3. Ext modulator (SR560 -> Marconi)

The long cable labled 'X Green Beat' was used to connect to the PZT (from the network analyzer).

Observations: The beat note kept floating between 0 and ~100 MHz

The PLL part of the circuit was tested coarsely with the spectrum analyzer function of the Agilent, where the loop was seen to stabilize when the carrier frequency of the Marconi was close to the instantaneous beat frequency.

Attachment 1: PM_measurement.jpeg
15074   Wed Dec 4 20:32:43 2019 gautamUpdateGeneralPLL for PM measurement

Were some cables from the ALS beat setup modified? I can't see the beat on the scope, and this elog doesn't say anything about cable connection rearrangement. At ~2311, I am reverting the setup to as it should be.

12076   Thu Apr 14 17:30:18 2016 ericqUpdateGeneralPLL measurement ongoing

Just a heads up that some equipment is hooked up at the PSL table for the repaired AUX laser PLL measurement, I plan to continue with it tonight.

I've taken a few spectra that, along with the PZT coefficient from the repair sheet, that suggest the noise level is ok (incoherent sum of AUX and PSL at about ~3e4 / f Hz/rtHz), but calibrated plots, etc. will follow in time.

13848   Wed May 16 18:52:50 2018 gautamConfigurationElectronicsPLL mysteries solved

[Koji, Gautam]

Summary:

As I suspected, when the SR560 is operated in 1 Hz, first order LPF mode, the (electronic) transfer function has a zero at ~5kHz (!!!).

Details:

This is what allowed the PLL to be locked with this setting with UGF of ~30kHz. On the evidence of Attachment #3, there is also some flattening of the electrical TF at low frequencies when the SR560 is driving the NPRO PZT. I'm pretty sure the flattening is not a data download error but since this issue needs further investigation anyway, I'm not reading too much into it. I fit the model with LISO but since we don't have low frequency (~1Hz) data, the fit isn't great, so I'm excluding it from the plots.

We also did some PLL loop characterization. We decided that the higher output range (10Vp bs 10Vpp for the SR560) of the LB1005 controller means it is a better option for the PLL. The lock state can also be triggered remotely. It was locked with UGF ~ 60kHz, PM ~45deg.

We also measured the actuation coefficient of the NPRO laser PZT to be 4.89 +/- 0.02 MHz/V. Quoted error is (1-sigma) from the fit of the linear part of the measured transfer function to a single pole at DC with unknown gain. I used the "clean" part of the measurement that extends to lower frequencies for the fit, as can be seen from the residuals plot. Good to know that even though the LDs are dying, the PZT is still going strong :D.

Remaining loop characterization (i.e. verification of correct scaling of in loop suppression with loop gain etc.) is left to Jon.

Measurement schemes:

1. OLG (Attachment #1) was measured using the usual IN1/IN2 technique.
2. PZT calibration (Attachment #2) was measured by injecting an excitation at the PLL control point.
• The ratio of the PLL error point (Volts) to Excitation (Volts) was measured using the SR785.
• The error point was calibrated by looking at the PLL open loop Vpp (corresponds to pi radians of phase shift).
• Dividing the fitted gain of the phase->Frequency conversion by the error point calibration, we get the PZT actuation coefficient.

Some other remarks:

1. In the swept-sine mode, the SR785 measures transfer functions by taking the ratio of complex FFT values of its inputs at the drive frequency. So the phase in particular is a good indicator of whether the measurement is coherent or not.
2. In all these measurements, the PLL gain is huge at low frequencies, and hence, the excitation is completely squished on propagating through the loop. E.g. a 10mV excitation is suppressed by a factor of ~60dB = 1000 to 10uV, and if the analyzer autoRange is set to UpOnly, it is easy to see how this is drowned at the IN1 input. This is why the measurements lose coherence below ~1 kHz.
3. It is easy to imagine implementing an EPICS servo that offloads the DC part of the LB box control signal to the SLOW frequency input on the Lightwave controller. This would presumably allow us to extend the lock timescales. We can also easily implement a PLL autolocker.
4. Preliminary investigation of the SR560 situation suggests that individual filter stages can only achieve a maximum stopband attenuation of 60dB relative to the passband. When we cascade two stages together, 120dB seems possible...
Attachment 1: PLLanalysis.pdf
Attachment 2: PZTcal.pdf
Attachment 3: SR560_funkiness.pdf
2679   Thu Mar 18 10:46:51 2010 KojiUpdateABSLPLL reconstructed

Last night (Mar 17) I checked the PLL setup as Mott have had some difficulty to get a clean lock of the PLL setting.

• I firstly found that the NPRO beam is not going through the Faraday isolator well. This was fixed by aligning the steering mirrors before the Faraday.

• The signal from the RF PD was send to the RF spectrum analyzer through a power splitter. This is a waist of the signal. It was replaced to a directional coupler.

• Tee-ing the PZT feedback to the oscilloscope was producing the noise in the laser frequency. I put the oscilloscope to the 600Ohm output of the SR560, while connectiong the PZT output to the 50Ohm output.

• In addition, 6dB+6dB attenuators have been added to the PZT feedback signal.

Now the beating signal is much cleaner and behave straight forward. I will add some numbers such as the PD DC output, RF levels, SR560 settings...

## Now I am feeling that we definitely need the development of really clean PLL system as we use PLL everywhere! (i.e. wideband PD, nice electronics, summing amplifiers, stop poking SR560, customize/specialize PDH box, ...etc)

2680   Thu Mar 18 12:27:56 2010 AlbertoUpdateABSLPLL reconstructed

Quote:

Last night (Mar 17) I checked the PLL setup as Mott had some difficulty to get a clean lock of the PLL setting.

• I firstly found that the NPRO beam is not going through the Faraday isolator well. This was fixed by aligning the steering mirrors before the Faraday.

• The signal from the RF PD was send to the RF spectrum analyzer through a power splitter. This is a waist of the signal. It was replaced to a directional coupler.
• Tee-ing the PZT feedback to the oscilloscope was producing the noise in the laser frequency. I put the oscilloscope to the 600Ohm output of the SR560, while connectiong the PZT output to the 50Ohm output.
• In addition, 6dB+6dB attenuators have been added to the PZT feedback signal.

Now the beating signal is much cleaner and behave straight forward. I will add some numbers such as the PD DC output, RF levels, SR560 settings...

## Now I am feeling that we definitely need the development of really clean PLL system as we use PLL everywhere! (i.e. wideband PD, nice electronics, summing amplifiers, stop poking SR560, customize/specialize PDH box, ...etc)

I also had noticed the progressive change of the aux NPRO alignment to the Farady.

I strongly agree about the need of a good and robust PLL.

By modifying the old PDH box (version 2008) eventually I was able to get a PLL robust enough for my purposes. At some point that wasn't good enough for me either.

I then decided to redisign it from scratch. I'm going to work on it. Also because of my other commitments, I'd need a few days/1 week for that. But I'd still like to take care of it. Is it more urgent than that?

2681   Thu Mar 18 13:40:35 2010 KojiUpdateABSLPLL reconstructed

We use the current PLL just now, but the renewal of the components are not immediate as it will take some time. Even so we need steady steps towards the better PLL. I appreciate your taking care of it.

Quote:

Quote:

Last night (Mar 17) I checked the PLL setup as Mott had some difficulty to get a clean lock of the PLL setting.

• I firstly found that the NPRO beam is not going through the Faraday isolator well. This was fixed by aligning the steering mirrors before the Faraday.

• The signal from the RF PD was send to the RF spectrum analyzer through a power splitter. This is a waist of the signal. It was replaced to a directional coupler.
• Tee-ing the PZT feedback to the oscilloscope was producing the noise in the laser frequency. I put the oscilloscope to the 600Ohm output of the SR560, while connectiong the PZT output to the 50Ohm output.
• In addition, 6dB+6dB attenuators have been added to the PZT feedback signal.

Now the beating signal is much cleaner and behave straight forward. I will add some numbers such as the PD DC output, RF levels, SR560 settings...

## Now I am feeling that we definitely need the development of really clean PLL system as we use PLL everywhere! (i.e. wideband PD, nice electronics, summing amplifiers, stop poking SR560, customize/specialize PDH box, ...etc)

I also had noticed the progressive change of the aux NPRO alignment to the Farady.

I strongly agree about the need of a good and robust PLL.

By modifying the old PDH box (version 2008) eventually I was able to get a PLL robust enough for my purposes. At some point that wasn't good enough for me either.

I then decided to redisign it from scratch. I'm going to work on it. Also because of my other commitments, I'd need a few days/1 week for that. But I'd still like to take care of it. Is it more urgent than that?

2684   Thu Mar 18 21:42:26 2010 KojiUpdateABSLPLL reconstructed

I checked the setup further more.

• I replaced the PD from NewFocus 1GHz one to Thorlabs PDA255.
• I macthed the power level of the each beam.

Now I have significant fraction of beating (30%) and have huge amplitude (~9dBm).
The PLL can be much more stable now.

Koji

2696   Mon Mar 22 22:11:26 2010 MottUpdateABSLPLL reconstructed

It looks like the PLL drifted alot over the weekend, and we couldn't get it back to 9 dBm.  We switched back to the new focus wideband PD to make it easier to find the beat signal.  I replaced all the electronics with the newly fixed UPDH box (#17) and we aligned it to the biggest beat frequency we could get, which ended up being -27 dBm with a -6.3V DC signal from the PD.

Locking was still elusive, so we calculated the loop gain and found the UGF is about 45 kHz, which is too high.  We added a 20 dB attenuator to the RF input to suppress the gain and we think we may have locked at 0 gain.  I am going to add another attenuator (~6 dB) so that we can tune the gain using the gain knob on the UPDH box.

Finally, attached is a picture of the cable that served as the smb - BNC adaptor for the DC output of the PD.  The signal was dependent on the angle of the cable into the scope or multimeter.  It has been destroyed so that it can never harm another innocent experiment again!

Attachment 1: IMG_0150.JPG
2697   Mon Mar 22 23:37:32 2010 MottUpdateABSLPLL reconstructed

We have managed to lock the PLL to reasonable stability. The RF input is attenuated by 26 dBm and the beat signal locks very close to the carrier of the marconi (the steps on the markers of the spectrum analyzer are coarse).  We can use the marconi and the local boost of the pdh box to catch the lock at 0 gain.  Once the lock is on, the gain can be increased to stabilize the lock.  The locked signals are shown in the first photo (the yellow is the output of the mixer and the blue is the output to the fast input of the laser.  If the gain is increased too high, the error signal enters an oscillatory regime, which probably indicates we are overloading the piezo.  This is shown in the second photo, the gain is being increased in time and we enter the non-constant regime around mid-way through.

Tomorrow I will use this locked system to measure the PZT response (finally!).

Attachment 1: 2010-03-22_23.14.00.jpg
Attachment 2: 2010-03-22_23.24.50.jpg
2703   Tue Mar 23 18:44:46 2010 MottUpdateABSLPLL reconstructed

After realigning and getting the lock today, I tried to add in the SR785 to measure the transfer function.  As soon as I turn on the piezo input on the PDH box, however, the lock breaks and I cannot reacquire it.  We are using an SR650 to add in the signal from the network analyzer and that has worked. We also swapped the 20 dB attenuator for a box which mimics the boost functionality (-20 dB above 100 Hz, 0 dB below 6Hz).  I took some spectra with the SR750, and will get some more with the network analyzer once Alberto has finished with it.

The SR750 spectra is posted below.  The SR750 only goes up to 100 kHz, so I will have to use the network analyzer to get the full range.

Attachment 1: NPRO_PLL_freqresp.png
2714   Thu Mar 25 17:29:48 2010 kiwamu, mottUpdateGreen LockingPLL two NPROs

In this afternoon, Mott and I tried to find a beat note between two NPROs which are going to be set onto each end table for green locking.

At first time we could not find any beats. However Koji found that the current of innolight NPRO was set to half of the nominal.

Then we increased the current to the nominal of 2A, finally we succeeded in finding a beat note.

Now we are trying to lock the PLL.

P.S. we also succeeded in acquiring the lock

 innolight lightwave T [deg] 39.75 37.27 current [A] 2 2 laser power [mW] 950 700

3920   Mon Nov 15 11:52:22 2010 kiwamuUpdateGreen LockingPLL with real green signal

Stabilizing the beat note frequency using Yuta's temperature servo (see this entry)

I was able to acquire the PLL of 80MHz VCO to the real green signal.

Some more details will be posted later.

3927   Mon Nov 15 17:10:59 2010 kiwamuUpdateGreen LockingPLL with real green signal

I checked the slow servo and the PLL of 80MHz VCO using the real green beat note signal.

The end laser is not locked to the cavity, so basically the beat signal represents just the frequency fluctuation of the two freely running lasers.

The PLL was happily locked to the green beat note although I haven't fedback the VCO signal to ETMX (or the temperature of the end laser).

It looks like we still need some more efforts for the frequency counter's slow servo because it increases the frequency fluctuation around 20-30mHz.

(slow servo using frequency counter)

As Yuta did before (see his entry), I plugged the output of the frequency counter to an ADC and fedback the signal to the end laser temperature via ezcaservo.

The peak height of the beat note is bigger than before due to the improvement of the PMC mode matching.

The peak height shown on the spectrum analyzer 8591E is now about -39dBm which is 9dB improvement.

The figure below is a spectra of the frequency counter's readout taken by the spectrum analyzer SR785.

When the slow temperature servo is locked, the noise around 20-30 mHz increased.

I think this is true, because I was able to see the peak slowly wobbling for a timescale of ~ 1min. when it's locked.

But this servo is still useful because it drifts by ~5MHz in ~10-20min without the servo.

Next time we will work on this slow servo using Aidan's PID control (see this entry) in order to optimize the performance.

In addition to that, I will take the same spectra by using the phase locked VCO, which provides cleaner signal.

(acquisition of the PLL)

In order to extract a frequency information more precisely than the frequency counter, we are going to employ 80MHz VCO box.

While the beat note was locked at ~ 79MHz by the slow servo, I successfully acquired the PLL to the beat signal.

However at the beginning, the PLL was easily broken by a sudden frequency step of about 5MHz/s (!!).

I turned off the low noise amplifier which currently drives the NPRO via a high-voltage amplifier, then the sudden frequency steps disappeared.

After this modification the PLL was able to keep tracking the beat signal for more than 5min.

(I was not patient enough, so I couldn't stand watching the signal more than 5min... I will hook this to an ADC)

 Quote: #3920 Some more details will be posted later.

10180   Thu Jul 10 19:37:54 2014 ManasaUpdateGeneralPM980 fiber tested OK

[Harry, Manasa]

This is the update from yesterday that Harry missed to elog.

We pulled out the first spool of the PM980 fiber yesterday and checked it using the illuminator at the SP table. Harry will be using this for all his tests and characterisation of the fiber.

1666   Wed Jun 10 09:28:14 2009 steveUpdatePSLPMC

The PMC alarm was on this morning. It was relocked at lower HV

The FSS_RMTEMP jumped 0.5 C so The PZT was compensating for it.

Attachment 1: pmctemphv.jpg
ELOG V3.1.3-