The PDFR system now has the capability to automatically run vectfit3.mat using a wrapper script named vectorfitzpk.m
This is done via a shell script being called from inside python that inturn runs the matlab script.
The PDFR system's interface and scripts have been updated to include quite a few more features.
On the interface side, there are buttons to open the previous plot for each PD and also a single button to run the scans on all PDs sequentially. The previous plot buttons actually open a softlink that is updated each time a measurement is taken.
Running a scan now pops up a terminal window to show messages that help understand whats going on.
In the background, the script now takes in the transfer function of the demodulator board in ZPK format and calibrates it out of each measurement. The parameters are given .dat files making it easier to replace the transfer function. (Remember my last elog which showed that the fitting of transfer functions were not really great and that I am going to use it anyway to get the script updated.) Also, the script now takes the delay in the RF cables and calibrates out that as well. So we no longer have the huge phase variations and the phase related to transimpedance are visible.
A test run was conducted today. Plots attached.
NOTE: The test can be conducted only on REFL 11,33,55,165 , AS55, and POX11.
POY11 has an optical fiber routed from this system, but there is no space to actually illuminate this PD. So it is currently not included in our system, even though there is a button for this.
POP22 has a fiber illuminating it, but its a unknown broadband PD. I do not know it's DC transimpedance or other values. Its just of matter of updating a few files that feed it's parameters into PDFR.
However, for the above PDs, the demodulator boards have been fit to a transfer function and the script is ready to go as soon as the above problems are fixed.
Conclusion: The plots look noisy. But, the transimpedance now resembles the one on 40-m wiki for all the PDs, both the shape and values.
There will be some errors that are induced because of improper demodulator TF fitting. This has to be taken care of eventually.
Work remaining: Create a canonical set of plots for each PD and set them as the baseline. These canonical plots will be plotted along with each measurement for easy comparison.
A well documented manual for the whole system clearly explaining where and how it takes all the parameters into account so that anybody can easy update just the essential information.
The PDFR system has been documented in the 40m wiki and all the relevant information about making changes and keeping it updated have been mentioned.
This pretty much wraps up my SURF 2014 project at the 40m lab.
AIM: Taking DC output readings with multimeter for each PD to create a database (required for transimpedance calculations), by taking off the table tops. Also, making sure each PD is illuminated properly.
What we did:
REFL11: Pinc = 0.91 mW VDC = 34.9 mV
REFL33: Pinc = 0.83 mW VDC = 33.2 mV
REFL55: Pinc = 1.08 mW VDC = 42.7 mV
REFL165: Pinc = 0.79 mW VDC = 115.3 mV
AS55: Pinc = 0.78 mW VDC = 31.3 mV
POX11: Pinc = 0.83 mW VDC = 34.7 mV
POP22**: Pinc = 1.08 mW VDC = 5.82 mV
POY11: Not illuminated; there was no optical fiber mount. Although, there was a fiber near it with a cap on the end. It also looks like there is no space to put in a new mount near the PD.
REF PD: Pinc = 1.19 mW VDC = 8.2 V (REF PD = New focus 1611)
**Note: The current POP 22 PD does not have 2 different outputs for DC and RF signals. I unplugged the RF cable from the output, took readings with the multimeter and then plugged back the RF cable.
I will calculate the responsivity for each PD and compare it to the expected values.
The following values are going to be entered in the param_[PDname].yml file for each PD. I am elogging them for future reference.
I got the values from combing schematics and old Elog entries. Please let me know if you believe the values are different.
In order to enable 'set terminal pdf' in gnuplot on Rosalba/Allegra, I installed PDFlib lite and gnuplot v4.2.6. to them.
(PDFlib lite is required to build the pdf-available version of gnuplot)
tar zxvf PDFlib-Lite-7.0.4p4.tar.gz
sudo make install
tar zxvf gnuplot-4.2.6.tar.gz
I've tweaked the ELOG code to allow uploading of PDFs by drag-and-drop into the main editor window. Once again we can bask in the glory of
I also modified the Y-Arm PDH box itself slightly. Previously, there was a flying 10k resistor from the SWEEP input to TP2. I don't see the point of this, so I moved it from TP2 across R19 (to the same point where it is on the gyro PDH boxes) to allow for excitation signals to be injected with the loop closed (i.e., with the SWEEP switch off). This is useful for OLTF measurements.
Once we adjust the phase we may be able to increase the servo gain for optimal locking. Unless it may be a good idea to increase the gain without optimizing the phase?
Check out this elog: ELOG 4354
If this summing box is still used as is, it is probably giving the demod phase adjustment.
I ended up choosing a different dither frequency for driving the NPRO PZT: 230 kHz, because the phase modulation response in that region is higher according to other data taken on an NPRO laser (see this entry). At 230 there is a dip in the AM response of the PZT.
I am driving the PZT at 230 kHz and 13 dBm using a function generator. I am then monitoring the RF output of a PD that is detecting light reflected off the cavity. (The dither frequency was below the RF cutoff frequency of the PD, but it was appearing in the "DC output", so I am actually taking the "DC output" of the PD, which has my RF signal in it, blocking the real DC part of it with a DC block, and then mixing the signal with the 230kHz sine wave being sent to the PZT.
I am monitoring the mixer output on an oscilloscope, as well as the transmission through the cavity. I am sweeping the laser temperature using a lock in as a function generator sending out a sine wave at 0.2 V and 5 mHz. When there is a peak in the transmission, the error signal coming from the mixer passes through zero.
My next step is to find or build a low pass filter with a pole somewhere less than 100 kHz to cut out the unwanted higher frequency signal so that I have a demodulated error signal that I can use to lock the laser to the cavity.
Air condition maintenance is happening. It should be done by 10am
Data from PEM now goes directly to OAF without using RFM. Transmission RFM -> OAF errors are gone as RFM has to read 30 channels less now.
Again kernel "protection error" occured as before with PEM model so OAF model could not start. I changed optimization flag to -02, this fixed the problem.
After talking with Steve, I had a look at the PEM's AA board, to see what the problem was.
Steve said the symptom he had noticed was that the Kepco power supplies which supply the +\- 5 V to the AA board were railing at their current limits as soon as he plugged the board in. Also, he smelled smoke.
I started with the power supplies, and saw that the 2 individual supplies each had a dV=5V, and that the one labeled +5V had the red wire on the + output of the power supply, and the black wire on the - output. The supply labeled -5V had the orange wire on the -output of the power suppy, and the black wire on the + output. Normally, you would expect that the 2 black wires are also connected together, and perhaps also to ground. But at least together, so that they share a common voltage, and you get +\- 5V. However these 2 power supplies are not connected together at all.
This implies that the connection must be made on the AA boards, which I found to be true. It seems a little weird to me to have that common ground set at the board, and not at the power supplies, but whatever. That's how it is.
The problem I found is this: The keyed connectors were made backward, so that if you put them in "correctly" according to the key, you end up shorting the +5V to the -5V, and the 2 black wires are not connected together. You have to put the keyed connectors in *backwards* in order to get the correct wires to the correct pins on the board. See the attached pdf figure.
Since these are internal board connections, and they should not ever be changed now that Steve has put in the adapter thing for the SCSI cable, I'm just leaving them as-is. Steve is going to write in huge letters in sharpie on the board how they're meant to be connected, although since this problem wasn't caught for many many years, maybe it won't ever be an issue again. Also, we're going to move over to the new Cymac system soon-ish. However, whomever made the power cable connector from the box to the board for this AA board was lazy and dumb.
After putting the connectors on the way they needed to be, Steve and I powered up the board, hooked up the SCSI cable in the back, and put a constant voltage (~1.3VDC battery) across various different channels, and confirmed that we could see this voltage offset in Dataviewer. (Kiwamu is hoarding both of our SRS function generators, so we couldn't put in a low freq sine wave like I normally would). Everything looked okie dokie, so I'll check the regular PEM channels tomorrow.
Steve will re-install the board in the rack in the morning.
As seen in the photo, the board has a strange bulge on the board,
and the color of the internal line around the bulge got darkened.
I don't trust this board any more. We should switch to the alternative one.
I wired all 32 channels going to the AA board directly to the ADC as described in the previous log. However, instead of using the old AA board and bypassing the whole circuit, I just used a breakout board as is shown in the first attachment. I put the board back in the rack and reconnected all of the cables.
The seismic BLRMs appear to be working again. A PSD of the BS seismometers is shown in attachment 2. Tomorrow I'll look at how much the ADC alone is suppressing the common mode 60 Hz noise on each of the channels.
Steve: 5 of ADC DAC In Line Test Boards [ D060124 ] ordered. They should be here within 10 days.
Yesterday, Koji and I noticed (from the wall StripTool traces) that the vertex seismometer RMS between 0.1-0.3 Hz in the X-direction increased abruptly around 6pm PDT. This morning, when I came in, I noticed that the level had settled back to the normal level. Trending the BLRMS channels over the last 24 hours, I see that the 0.3-1 Hz band in the Z direction shows some anomalous behaviour almost in the exact same time-band. Hard to believe that any physical noise was so well aligned to the seismometer axes, I'm inclined to think this is indicative of some electronics issues with the Trillium interface unit, which has been known to be flaky in the past.
I looked into the seismometer situation a bit more today. Here is the story so far - I think more investigation is required:
Attachment #2 has some spectrograms (they are rather large files). They suggest that the increase in noise in the 0.1-0.3 Hz band in the BS seismometer X channel is real - but there isn't a corresponding increase in the other two seismometers, so the problem could still be electronics related.
Joe showed me what was what with adding DAQ channels, and I have begun building a simulink model to acquire the PEM channels.
My models is in: /cvs/cds/rtcds/caltech/c1/core/advLigoRTS/src/epics/simLink/c1pem.mdl
Next on the to do list in this category: test which input connector goes with which channel (hopefully it's linear, exactly as one would think), and give the channels appropriate names.
Rana asked me to include add slow outputs (OUT16) of the seismometer BLRMS channels to the frames.
All of the PEM slow channels are already set up in c1/chans/daq/C1EDCU_PEM.ini, but up to this point, daqd had no knowledge of this file, since it wasn't included in c1/target/fb/master, which defines all the places to look for files describing channels to be written to disk. This file already includes lines for C1EDCU_LSC.ini and such, which from old elogs, looks like was set up by hand for subsystems we care about.
Hence, since we now care about slow trends for the PEM subsystem, I have added a line to the daqd master file to tell it to save the PEM slow channels. This looks to have increased the size of the individual 16 second frame files from 57MB to 59MB, which isn't so bad.
Still processing, but I think it should work fine once we have a day of data. Until then, here's the summary pages so far, including Vac channels:
FSS_RMTEMP is moving up and daily fluctuations are less . 120 and 16 days plots are below.
I've disabled the alarm for PEM_count_half, using the mask in the 40m.alhConfig file. We can't do anything about it, and it's just annoying.
Sorry for flooding the ELOG about the PEM channels. Today I
- Changed all of the GUR1 and GUR2 filters to elliptic, and lowered the orders of their low-pass filters.
- Lowered the order of the low-pass filters on the STS channels
- Changed the parameters in seismic.strip, which I saved as MashaTemplate2.
Attached is the most recent status of the channels as seen with StripTools:
I'm not currently sure how to apply my template to seismic.strip shown on the wall (I saved it as seismic.strip on Pianossa and copied the old file to seismic.stripOld). I understand the job is being run on Megatron. I'll play around with this later tomorrow. (In other words, the display currently on the wall, while it does not have the Nan spikes like yesterday and this morning does not currently display the template I made).
C1: PEM-count channels are dead since August 12, 2010
I've added the PEM_SLOW.ini file to the fb master file, which should give us the slow seismic RMS channels when the framebuilder is restarted. Example channels:
I also updated the path to the other _SLOW.ini files.
I will do it first thing in the am tomorrow, when Kiwamu is not busy getting real work done.
Here's is a the diff for /opt/rtcds/caltech/c1/target/fb/master:h
controls@pianosa:/opt/rtcds/caltech/c1/target/fb 1$ diff -u master~ master
--- master~ 2011-09-15 17:32:24.000000000 -0700
+++ master 2012-03-29 19:51:52.000000000 -0700
@@ -7,11 +7,12 @@
The framebuilder seems to have been restarted, or restarted on it's own, so these channels are now being acquired.
Below is a minute trend of a smattering of the available RMS channels over the last five days.
I wanted to do a more robust measurement of PER of PM fibers for FOL, so I thought up this scheme.
I put together a setup as depicted below in order to take measurements of PER.
The first thing to do was to calibrate the whole setup. In order to do so, I first used the quarter and half wave plates closest to the NPRO to eliminate as much ellipticity from the output beam as possible, and then rotate the newly linearized light to be in alignment with the transmittance of the first polarizing beam splitter (P-Polarization).
I then aligned the fiber's fast axis with the P-Polarization on both the input and output sides. This was important so that no virtual ellipticity would be measured in the final measurement of PER.
I then mode matched and fiber coupled the first PBS output into the fibers, to about 30 mW (~60% coupling).
I wanted to measure both intensity of P and S simultaneously, so as to minimize the random little time-varying changes that would affect the measurements, so I used a powermeter and a PD, calibrated with the aformentioned powermeter.
In order to be able to compare the photodiode (PDA520) output to the powermeter (Orion) output, I fixed them each in their positions, and varied the laser power to produce the type of linear relationship we expect to see between PD Voltage and Optical Power. In this case, the conversion was P = V*2.719.
As opposed to the first method, which took only one datum, this method records P and S simultaneously, at different points through rotation of a linearly polarized beam.
Using the second HWP, I rotated the linearly polarized beam before it entered the fiber, at each point, recording the outputs of the PD and the Powermeter.
These data were then converted to be the same units, and fit to a sine wave.
As you can see, the intensities vary nearly identically, at a half wavelength phase difference, which is what one expects in this case. The PER of each polarization can be calculated by dividing the maximum value of one by the minimum of the other, and vice versa. The fact that these oscillate as we expect shows that the beam is relatively well linearized, and essentially that everything is working as it is assumed to be.
By looking at these fits, however, it is visible that they do not overlap with the actual extrema of the data. So, in order to produce more realistic values of extrema, those particular regions were fit to second order polynomials.
The values of these extrema yield the following measurements:
(SMin / PMax) = 0.007 +/- .004 ---> -21.54 +/- 2.48 dB
(PMin / SMax) = 0.022 +/- .009 ---> -16.58 +/- 1.78 dB
The problem I find with these measurements is that they're hard to reproduce.
Plus they seem high, since non-PM fibers advertise extinction ratios around -30 dB., plus I measured it at roughly -24 dB the first time I tried.
The next thing to do in terms of fiber characterization is to measure the frequency noise they introduce.
With respect to FOL, I just need some time to work on the PSL table, and at the Y end to couple the dumped SHG light, and then we can start using 1064nm beat notes to test//implement the feedback control system.
The PI pzt holders are back from the shop. They are numbered 1, 2 & 3 and machined to match.
Tapered black delrin opener is to gauge the gap if it is too small to fit pzt. This is to prevent holder to be opened too much.
One is broken, two are ready to steer green and 3 available in un known condition
I also have a functional one on my desk, which has one of the wires repaired.
Increased the Integral gain (from -1 to -4) on the EX temperature controller. This didn't work a few weeks ago, but now with the added P gain, it seems stable. Daily temperature swings are now ~3x smaller.
Notes for Kira on what we need to do tomorrow (Friday):
For those who are flabbergasted by the way I calibrated the TEMP_MON channel from volts to deg C, here's how:
use the 'scale' and 'translate' fields to change the slope and offset for calibration in the obvious ways
I added an out of loop sensor to the can by placing the lab temperature sensor inside the can. I'm not sure which channel is logging this temperature though. I also noticed that the StripTool still had the old misspelled name for the temperature readout so I fixed that as well.
I've attached a picture of the setup.
Kiwamu and I roughly calibrated the analogue output from the SR620 frequency counter yesterday. The input channel, intuitively named C1:PSL-126MOPA_126MON, now reads the measured frequency in MHz with an error of about 0.1MHz - this is, I think, due to the bit noise on the D/A conversion that Kiwamu discovered earlier. That is, the output range of the SR620 corresponds to around 100MHz and is digitized at 10-bit resolution, and ...
100MHz/(10^2) ~= 0.098MHz. [Sad Face]
We set the EPICS range to [-100, 100] (corresponding to [-5V, 5V]), connected a Marconi to the Freq Counter, input a variety of different frequencies and measured the counts on the EPICS channel.
The linear fit to the calibration data was F = 2.006*EPICScount - 0.2942. From this we worked out the maximum and the minimum for the range settings that give the channel in MHz: EGUF = -200.8942 and EGUL = 200.3058. The previous range was [-410, 410]
Today I and EricQ went inside the lab and set up the cables running from the a DAC channel into PZT input so that we can use the PID controller to tune in the PZT offset to maintain the beat note within a detectable range (This is plan B as the main plan of actuating on the laser temperature can be achieved only after the fiber setup with the PSL is ready). I obtained all the poles and zeroes of plant and started designing a PID loop to test it with the existing system.
I will put in my PID values into the already existing PERL controller code (that is used for controller design in the 40m) and run tests with the PID loop while actuating on the PZT offset.
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.
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.
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.
That's not unreasonable. But if we try
grep "perl" /cvs/cds/rtcds/caltech/c1/scripts/*/*
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.
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.
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/
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.
Right now the script only passes the initial sanities checks, that is:
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.
EPICS channels added:
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.
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.
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.
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.