I think we should discuss interlock possibilities at a 40m meeting. I'm reluctant to make the system more complicated, but perhaps we can find ways to reduce the reliance on the turbo pump readbacks. I agree they've proven to be the least reliable.
While we may be able to improve the tolerance to certain kinds of hardware malfunctions (and if so, we should), I don't see interlocks triggering on abnormal behavior of critical equipment as the root problem. As I see it, our bigger problem is with all the malfunctioning, mostly end-of-lifetime pieces of vacuum equipment still in use. If we can address the hardware problems, as I'm trying to do with replacements [ELOG 15412], I think that in itself will make the interlocking much less of an issue.
So why not just have a special mode for the interlock code during pumpdown and venting, and during normal operation we expect the main volume pressure to be <100uTorr so the interlock trips if this condition is violated? These can just be EPICS buttons on the Vac control MEDM screen. Both of these procedures are not "business as usual", and even if we script them in the future, it's likely to have some operator supervising, so I don't think it's unreasonable to have to switch between these modes. I just think the pressure gauges have demonstrated themselves to be much more reliable than these TP serial readbacks (as you say, they worked once upon a time, but that is already evidence of its flakiness?). The Pirani gauges are not ultra-reliable, they have failed in the past, but at least less frequently than this serial comm glitching. In fact, if these readbacks are so flaky, it's not impossible that they don't signal a TP shutdown? I just think the real power of having these multi-channel diagnostics is lost without some AND logic - a turbopump failure is likely to result in an increase in pump current and temperature increase and pump speed decrease, so it's not the individual channel values that should be determining if an interlock is tripped.
Ok, this can be added pretty easily. Its value will just be toggled between 1 and 0 every time the interlock server raises/clears the existing string channel. Adding the channel will require restarting the whole vac IOC, so I'll do it at a time when Jordan is on hand in case something fails to come back up.
It would be better to have a flag channel, might be useful for the summary pages too. I will make it if it is too much trouble.
For this particular email service, ideally the email should be sent out as soon as the interlock is tripped, so this would require a line of code to be added to the main interlock code. Which I guess would require a restart of the interlock service. So let me know when you guys plan to do the dry-pump tip seal replacement operation (when I presume valves will be closed anyways) so that we can do this in a minimally invasive way.
[Suresh and Kevin]
We placed the quarter wave plate in front of the 2W laser and moved the half wave plate forward. To make both wave plates fit, we had to rotate one of the clamps for the laser. We optimized the angles of both wave plates so that the power in the reflection from the PBS was minimized and the transmitted power through the faraday isolator was maximized. This was done with 2.1 A injection current and 38°C crystal temperature.
Next, I will make plots of the reflected power as a function of half wave plate angle for a few different quarter wave plate rotations.
[Koji and Kevin]
We measured the reflection from the PBS as a function of half wave plate rotation for five different quarter wave plate rotations. Before the measurement we reduced the laser current to 1 A, locked the PMC, and recorded 1.1 V transmitted through the PMC. During the measurements, the beam was blocked after the faraday isolator. After the measurements, we again locked the PMC and recorded 1.2 V transmitted. The current is now 2.1 A and both the PMC and reference cavities are locked.
I will post the details of the measurement tomorrow.
I measured the reflected power from the PBS as a function of half wave plate rotation for five different quarter wave plate rotations.
The optimum angles that minimize the reflected power are 330° for the quarter wave plate and 268° for the half wave plate.
The following data was taken with 2.102 A laser current and 32.25° C crystal temperature.
For each of five quarter wave plate settings around the optimum value, I measured the reflected power from the PBS with an Ophir power meter. I measured the power as a function of half wave plate angle five times for each angle and averaged these values to calculate the mean and uncertainty for each of these angles. The Ophir started to drift when trying to measure relatively large amounts of power. (With approximately 1W reflected from the PBS, the power reading rapidly increased by several hundred mW.) So I could only take data near the minimum reflection accurately.
The data was fit to P = P0 + P1*sin^2(2pi/180*(t-t0)) with the angle t measured in degrees with the following results:
where V is the visibility V = 1- P_max/P_min. These fits are shown in attachment 1. We would like to understand better why we can only reduce the reflected light to ~150 mW. Ideally, we would have V = 1. I will redo these measurements with a different power meter that can measure up to 2 W and take data over a full period of the reflected power.
Q1. Suppose the laser beam has a certain (i.e. arbitrary) polarization state but contains only TEM00. Also suppose the PSB is perfect (reflect all S and transmit all P). What results do you expect from your expereiment?
Q2. Suppose the above condition but the PBS is not perfect (i.e. reflects most of S but also small leakage of P to the reflection port.) How are the expected results modified?
Q3. In reality, the laser may also contain some thing dirty (e.g. deporarization in the laser Xtal, higher order modes in a certain polarization but different from the TEM00's one, etc). What actually is the cause of 170mW rejection from the PBS? Can we improve the transmitted power through the PBS?
Q4. Why is the visibility for the lambda/4 with 330deg better than the one with 326deg? Yes, as I already explained to Kevin, I suppose it was caused by the lack of the data points in the wider angle ranges.
Rich Abbott, Rana
Summary: We found that the 3mm InGaAs photodiodes from eGTRAN which are being used for the DC Readout in eLIGO are bad. The QE is ~50%. We will have to replace them ASAP.
Valera and Nic Smith have pointed out out a factor of ~2 discrepancy between the estimated power transmission to the dark port in H1 and L1. So we decided to measure the QE of the accused diodes.
The data of the QE and dark current are attached here.
We used a 1064 nm CrystaLaser (which does not have a very stable power output). We attenuated the light with an ND1.0 for all measurements.
The photocurrent is estimated by reading out the voltage across one leg of the differential drive of the DC PD preamp. The photocurrent goes across a 100 Ohm resistor and then through 2 gain of 1 stages to get to this testpoint, so the overall transimpedance gain is 100 Ohms for this measurement.
By far, the Ophir power meter is the biggest source of error. Its absolute calibration is only 5% and the variation across the sensor face is ~5%. There are some hot and not hot spots on the face which can make even more variation, but we tried to avoid these.
We also inserted the power meter very close to the time when we read the voltage, so that the photocurrent and power estimates are made within 10 seconds of each other. This should reduce the error from the laser's power fluctuations.
All diodes still had the glass case on. We measured the reflected power to be ~5-7% of the incident power. This reflected power is NOT accounted for in these estimates.
Punch line: The eGTRAN diodes that we currently use are definitely bad. The JDSU and EG&G 2mm diodes have a better QE. We should immediately purchase 3 mm versions and get them cut and measured to be ready for the Sep. 1 commissioning surge.
Now that we have a model of how the SS and IIR filters work we can get to the problem of how to measure the quantization noise in each of the systems. Den Martynov's thesis talks a little about this. from my understanding: He measured quantization noise by having two filters using two types of variables with different numbers of bits. He had one filter with many more bits than the second one. He fed the same input signal to both filters then recorded their outputs x_1 and x_2, where x_2 had the higher number of bits. He then took the difference x_1-x_2. Since the CDS system uses double format, he assumes that quantization noise scales with mantissa length. He can therefore extrapolate the quantization noise for any mantissa length.
Here is the Code that follows the following procedure (as of today at least)
This problem is a little harder than I had originally thought. I took Rana's advice and asked Aaron about how he had tackled a similar problem. We came up with a procedure explained below (though any mistakes are my own):
From these three equations, we calculate the three quantities: , , and which are calculated by:
from these quantities, we can calculate three values: , , and since these are just estimates we are using a bar on top. These are calculated using:
using these estimates we can then estimate using the formula:
we can average the three estimates for to come up with one estimate.
This procedure should be able to give us a good estimate of the quantization noise. However, in the graph shown in the attachments below show that the noise follows the transfer function of the model to begin with. I would not expect this to be true so I believe that there is an error in the above procedure or in my code that I am working on finding. I may have to rework this three-corner hat approach. I may have a mistake in my code that I will have to go through.
I would expect the quantization noise to be flatter and not follow the shape of the transfer function of the model. Instead, we have what looks like just the result of random noise being filtered through the model.
The first real step is being able to quantify the quantization noise but after I fix the issues in my code I will be able to start liking at optimal model design for both the state-space model and the direct form II model. I have been looking through the book "Quantization noise" by Bernard Widrow and Istvan Kollar which offers some good insights on how to minimize quantization noise.
I have not been able to figure out a way to make the system that Aaron and I talked about. I'm not even sure it is possible to pull the information out of the information I have in this way. Even the book uses a comparison to a high precision filter as a way to calculate the quantization noise:
"Quantization noise in digital filters can be studied in simulation by comparing the behavior of the actual quantized digital filter with that of a refrence digital filter having the same structure but whose numerical calculations are done extremely accurately."
-Quantization Noise by Bernard Widrow and Istvan Kollar (pg. 416)
"Quantization noise in digital filters can be studied in simulation by comparing the behavior of the actual quantized digital filter with that of a refrence digital filter having the same structure but whose numerical calculations are done extremely accurately."
-Quantization Noise by Bernard Widrow and Istvan Kollar (pg. 416)
Thus I will use a technique closer to that used in Den Martynov's thesis (see appendix B starting on page 171). A summary of my understanding of his method is given here:
A filter is given raw unfiltered gaussian data then it is filtered and the result is the filtered data thus we get the result: where is the raw noise filtered through an ideal filter and is the difference which in this case is the quantization noise. Thus I will input about 100-1000 seconds of the same white noise into a 32-bit and a 64-bit filter. (hopefully, I can increase the more precise one to 128 bit in the future) then I record their outputs and subtract the from each other. this should give us the Quantization error :
and since because they are both running through ideal filters:
and since in this case, we are assuming that the higher bit-rate process is essentially noiseless we get the Quantization noise .
If we make some assumptions, then we can actually calculate a more precise version of the quantization noise:
"Since aLIGO CDS system uses double precision format, quantization noise is extrapolated assuming that it scales with mantissa length"
-Denis Martynov's Thesis (pg. 173)
"Since aLIGO CDS system uses double precision format, quantization noise is extrapolated assuming that it scales with mantissa length"
-Denis Martynov's Thesis (pg. 173)
From this assumption, we can say that the noise difference between the 32-bit and 64-bit filter outputs: is proportional to the difference between their mantissa length. by averaging over many different bit lengths, we can estimate a better quantization noise number.
I am building the code to do this in this file
I have coded up the procedure in the previous post: The result does not look like what I would expect.
As shown in Attachment1 I have the power spectrum of the 32-bit output and the 64-bit output as well as the power spectrum of the two subtracted time series as well as the subtracted power spectra of both. unfortunately, all of them follow the same general shape of the raw output of the filter.
I would not expect quantization noise to follow the shape of the filter. I would instead expect it to be more uniform. If anything I would expect the quantization noise to increase with frequency. If a high-frequency signal is run through a filter that has high quantization noise then it will severely degrade: i.e. higher quantization noise.
This is one reason why I am confused by what I am seeing here. In all cases including feeding the same and different white noise into both filters, I have found that the calculated quantization noise is proportional to the response of the filter. this seems wrong to me so I will continue to play around with it to see if I can gain any intuition about what might be happening.
I suggest that you
First and foremost I have the updated bode plot with the mode moved to 10 Hz. See Attachment 1. Note that the comparison measurement is a % difference whereas in the previous bode plot it was just the difference. I also wrapped the phase so that jumps from -180 to 180 are moved down. This eliminates massive jumps in the % difference.
Next, I have two comparison plots: 32 bit and 64bit. As mentioned above I moved the mode to 10 Hz and just excited both systems at 3.4283Hz with an amplitude of 1. As we can see on the plot the two models are practically the same when using 64bits. With the 32bit system, we can see that the noise in the IIR filter is much greater than in the State-space model at frequencies greater than our mode.
Note about windowing and averaging: I used a Hanning window with averaging over 4 neighbor points. I came to this number after looking at the results with less averaging and more averaging. In the code, this can be seen as nperseg=num_samples/4 which is then fed into signal.welch
I added mpmath to the quantization noise code. mpmath allows me to specify the precision that I am using in calculations. I added this to both the IIR filters and the State-space models although I am only looking at the IIR filters here. I hope to look at the state-space model soon.
I also added a new notebook which you can find HERE. This notebook creates a signal by summing two sine waves and windowing them.
Then that signal is passed through our filter that has been limited to a specific precision. In our case, we pass the same signal through a number of filters at different precisions.
Next, we take the output from the filter with the highest precision, because this one should have the lowest quantization noise by a significant margin, and we subtract the outputs of the lower precision filters from it. In summary, we are subtracting a clean signal from a noisy signal; because the underlying signal is the same, when we subtract them the only thing that should be left is noise. and since this system is purely digital and theoretical the limiting noise should be quantization noise.
Now we have a time series of the noise for each precision level (except for our highest precision level but that is because we are defining it as noiseless). From here we take a power spectrum of the result and plot it.
After this, we can calculate a frequency-dependent SNR and plot it. I also calculated values for the SNR at the frequencies of our two inputs.
This is the procedure taken in the notebook and the results are shown below.
Analysis of Results:
The first thing we can see is that the precision levels 256 and 128 bits are not shown on our graph. the 256-bit signal was our clean signal so it was defined to have no noise so it cant be plotted. The 128-bit signal should have some quantization noise but I checked the output array and it contained all zeros. after further investigation, I found that the quantization noise was so small that when the result was being handed over from mpmath to the general python code it was rounding those numbers to zero. To overcome this issue I would have to keep the array as a mpmath object the entire time. I don't think this is useful because matplotlib probably couldn't handle it and it would be easier to just rewrite the code in C.
The next thing to notice is sort of a sanity check thing. In general, low precision filters yield higher noise than high precision. This is a good quick sanity check. However, this does not hold true at the low end. we can see that 16-bit actually has the highest noise for most of the range. Chris pointed out that at low precisions that quantization noise can become so large that it is no longer a linearly coupled noise source. He also noted that this is prone to happen for low precision coefficients with features far below the Nyquist frequency like I have here. This is one explanation that seems to explain the data especially because this ambiguity is happening at 16-bit and lower as he points out.
Another thing that I must mention, even if it is just a note to future readers, is that quantization noise is input dependent. by changing the input signal I see different degrees of quantization noise.
Analysis of SNR:
One of the things we hoped to accomplish in the original plan was to play around with the input and see how the results changed. I mainly looked at how the amplitude of the input signal scaled the SNR of the output. Below I include a table of the results. These results were taken from the SNR calculated at the first peak (see the last code block in the notebook) with the amplitude of the given sine wave given at the top of each column. this amplitude was given to both of the two sine waves even though only the first one was reported. To see an example, currently, the notebook is set up for measurement of input amplitude 10.
As we can see from the table above the SNR does not seem to relate to the amplitude of the input. in multiple instances, the SNR dips or peaks in the middle of our amplitude range.
This looks great. I think what we want to see mainly is just the noise in the 32 bit IIR filtering subtracted from the 64 bit one.
It would be good if Tega can look through your code to make sure there's NO sneaky places where python is doing some funny casting of the numbers. I didn't see anything obvious, but as Chris points out, these things can be really sneaky so you have to be next level paranoid to really be sure. Fox Mulder level paranoia.
And, we want to see a comparison between what you get and what Denis Martynov put in an appendix of his thesis when comparing the Direct Form II, with the low-noise form (also some slides from Matt Evans on thsi from a ~decade agoo). You should be able to reproduce his results. He used matlab + C, so I am curious to see if it can be done all in python, or if we really need to do it in C.
And then...we can make this a part of the IFOtest suite, so that we point it at any filter module anywhere in LIGO, and it downloads the data and gives us an estimate of the digital noise being generated.
Tega and I have gone through the IIR Filter code and optimized it to make sure there aren't any areas that force high precision to be down-converted to low precision.
For the new biquad filter we have run into the issue where the gain of the filter is much higher than it should be. Looking at attachments 1 and 2, which are time series comparisons of the inputs and outputs from the different filters, we see that the scale for the output of the Direct form II filter shown in attachment 1 on the right is on the order of 10^-5 where the magnitude of the response of the biquad filter is on the order of 10^2. other than this gain the responses look to be the same.
I am not entirely sure how this gain came into the system because we copied the c code that actually runs on the CDS system into python. There is a gain that affects the input of the biquad filter as shown on this slide of Matt Evans Slides. This gain, shown below as g, could decrease the input signal and thus fix the gain. However, I have not found any way to calculate this g.
With this gain problem we are left with the quantization noise shown in Attachment 4.
I have controlled the state space filter to act with a given precision level. However, my code is not optimized. It works by putting the input state through the first state-space equation then integrating the result, which finally gets fed through the second state-space equation.
This is not optimized and gives us the resulting quantization noise shown in attachment 5.
However, the state-space filter also has a gain problem where it is about 85 times the amplitude of the DF2 filter. Also since the state space is not operating in the most efficient way possible I decided to port the code chris made to run the state-space model to python. This code has a problem where it seems to be unstable. I will see if I can fix it
I am trying to replicate the simulation done by Matt Evans in his presentation (see Attachment 1 for the slide in particular).
He defines his input as so he has two inputs one of amplitude 1 at 1 Hz and one of amplitude 10^-9 at 1/4th the sampling frequency in this case: 4096 Hz
For his filter, he uses a fourth-order notch filter. To achieve this filter I cascaded two second-order notch filters (signal.iirnotch) both with locations at 1 Hz and quality factors of 1 and 1e6. as specified in slide 13 of his presentation.
I used the same procedure outlined here. My results are posted below in attachment 2.
Analysis of results:
As we can see from the results posted below the results don't match. there are a few problems that I noticed that may give us some idea of what went wrong.
First, there is a peak in the noise around 35 Hz. this peak is not shown at all in Matt's results and may indicate that something is inconsistent.
the second thing is that there is no peak at 4096 Hz. This is clearly shown in Matt's slides and it is shown in the input spectrum so it is strange that it does not appear in the output.
My first thought was that the 4kHz signal was being entered at about 35Hz but even when you remove the 4kHz signal from the input it is still there. The spectrum of the input shown in Attachment 3 shows no features at ~35Hz.
The Input filter, Shown in attachment 4 shows the input filter, which also has no features at ~35Hz. Seeing how the input has no features at ~35Hz and the filter has no features at ~35Hz there must be either some sort of quantization noise feature there or more likely there is some sort of sampling effect or some effect of the calculation.
To figure out what is causing this I will continue to change things in the model until I find what is controlling it.
I have included a Zip file that includes all the necessary files to recreate these plots and results.
I made the first pass at a tool to measure the quantization noise of specific filters in the 40m system. The code for which can be found here. It takes the input to the filter bank and the filter coefficients for all of the filters in the filter bank. it then runs the input through all the filters and measures the quantization noise at each instance. It does this by subtracting the 64-bit output from the 32-bit output. Note: the actual system is 64 bit so I need to update it to subtract the 64-bit output from the 128-bit output using the long double format. This means that it must be run on a computer that supports the long double format. which I checked and Rossa does. The code outputs a number of plots that look like the one in Attachment 1. Koji suggested formatting a page for each of the filters that is automatically generated that shows the filter and the results as well as an SNR for the noise source. The code is formatted as a class so that it can be easily added to the IFOtest repo when it is ready.
I tracked down a filter that I thought may have lower thermal noise than the one that is currently used. The specifics of this will be in the DCC document version 2 that I am updating but a diagram of it is found in attachment 2. Preliminary calculations seemed to show that it had lower quantization noise than the current filter realization. I added this filter realization to the c code and ran a simple comparison between all of them. The results in Attachment 3 are not as good as I had hoped. The input was a two-toned sin wave. The low-level broadband signal between 10Hz and 4kHz is the quantization noise. The blue shows the current filter realization and there shows the generic and most basic direct form 2. The orange one is the new filter, which I personally call the Aircraft Biquad because I found it in this paper by the Hughes Aircraft Company. See fig 2 in paper. They call it the "modified canonic form realization" but there are about 20 filters in the paper that also share that name. in the DCC doc I have just given them numbers because it is easier.
1) I need to make the review the qnoisetool code to make it compute the correct 64-bit noise.
a) I also want to add the new filter to the simulation to see how it does
2) Make the output into a summary page the way Koji suggested.
3) complete the updated DCC document. I need to reconcile the differences between the calculation I made and the actual result of the simulation.
P. P. Vaidyanathan wrote a chapter in the book "Handbook of Digital Signal Processing: Engineering Applications" called "Low-Noise and Low-Sensitivity Digital Filters" (Chapter 5 pg. 359). I took a quick look at it and wanted to give some thoughts in case they are useful. The experts in the field would be Leland B. Jackson, P. P. Vaidyanathan, Bernard Widrow, and István Kollár. Widrow and Kollar wrote the book "Quantization Noise Roundoff Error in Digital Computation, Signal Processing, Control, and Communications" (a copy of which is at the 40m). it is good that P. P. Vaidyanathan is at Caltech.
Vaidyanathan's chapter is serves as a good introduction to the topic of quantization noise. He starts off with the basic theory similar to my own document on the topic. From there, there are two main relevant topics to our goals.
The first interesting thing is using Error-Spectrum Shaping (pg. 387). I have never investigated this idea but the general gist is as poles and zeros move closer to the unit circle the SNR deteriorates so this is a way of implementing error feedback that should alleviate this problem. See Fig. 5.20 for a full realization of a second-order section with error feedback.
The second starts on page 402 and is an overview of state space filters and gives an example of a state space realization (Fig. 5.26). I also tested this exact realization a while ago and found that it was better than the direct form II filter but not as good as the current low-noise implementation that LIGO uses. This realization is very close to the current realization except uses one less addition block.
Overall I think it is a useful chapter. I like the idea of using some sort of error correction and I'm sure his other work will talk more about this stuff. It would be useful to look into.
One thought that I had recently is that if the quantization noise is uncorrelated between the two different realizations then connecting them in parallel then averaging their results (as shown in Attachment 1) may actually yield lower quantization noise. It would require double the computation power for filtering but it may work. For example, using the current LIGO realization and the realization given in this book it might yield a lower quantization noise. This would only work with two similarly low noise realizations. Since it would be randomly sampling two uniform distributions and we would be going from one sample to two samples the variance would be cut in half, and the ASD would show a 1/√2 reduction if using realizations with the same level of quantization noise. This is only beneficial if the realization with the higher quantization noise only has less than about 1.7 times the one with the lower noise. I included a simple simulation to show this in the zip file in attachment 2 for my own reference.
Another thought that I had is that the transpose of this low-noise state-space filter (Fig. 5.26) or even of LIGO's current filter realization would yield even lower quantization noise because both of their transposes require one less calculation.
This post serves as a summary and description of code to run to test the impacts of quantization noise on a state-space implementation of the suspension model.
Purpose: We want to use a state-space model in our suspension plant code. Before we can do this we want to test to see if the state-space model is prone to problems with quantization noise. We will compare two models one for a standard direct-ii filter and one with a state-space model and then compare the noise from both.
First I built a basic signal generator that can produce a sine wave for a specified amount of time then can produce a zero signal for a specified amount of time. This will let the model ring up with the sine wave then decay away with the zero signal. This input signal is generated at a sample rate of 2^16 samples per second then stored in a numpy array. I later feed this back into both models and record their results.
The code can be seen here
The state-space model takes in the list of excitation values and feeds them through a loop that calculates the next value in the output.
Given that the state-space model follows the form
the model has three parts the first equation, an integration, and the second equation.
This system is the coded form of the block diagram of the state space representation shown in attachment 1
The direct form 2 filter works in a much simpler way. because it involves no integration and follows the block diagram shown in Attachment 2, we can use a single difference equation to find the next output. However, the only complication that comes into play is that we also have to keep track of the w(n) seen in the middle of the block diagram. We use these two equations to calculate the output value
, where w[n] is
Bit length Control:
To control the bit length of each of the models I typecast all the inputs using np.float then the bit length that I want. This simulates the computer using only a specified bit length. I have to go through the code and force the code to use 128 bit by default. Currently, the default is 64 bit which so at the moment I am limited to 64 bit for highest bit length. I also need to go in and examine how numpy truncates floats to make sure it isn't doing anything unexpected.
The bode plot at the bottom shows the transfer function for both the IIR model and the state-space model. I generated about 100 seconds of white noise then computed the transfer function as
which is the cross-spectral density divided by the power spectral density. We can see that they match pretty closely at 64 bits. The IIR direct II model seems to have more noise on the surface but we are going to examine that in the next elog
I have tried to make the quadrant magnetic levitation work but unfortunately I did not succeed. During the experiment, I have made
the following changes to the circuit and setup:
(1) I added small resistors (6K) in parallel to R11, R23, R35 and R47 (indicated in the following schematics) to increase
the control bandwidth from 20 Hz to 80 Hz.
(2) I changed RLED1, RLED2, RLED3, RLED4 from 2.2K to 1.5K in the LED driver such that the current of the
LED increases and in turn the displacement sensitivity increases.
(3) I changed R51 and R51 (in the differencing block for PD1 and PD2) from 5K to 1 K. Correspondingly,
I increased R52 and R54 from 5K to 50K. This changes increase the gain in the differential control by a
factor of 50, which compensates the gain loss after increasing the control bandwidth.
(4) The trim pots in the coil drive block have the following values: 100K for pot1 and pot4, 1K fro pot 2 and pot3.
To increase the gain, I replaced R17, R30, R31, R41 by 102 Om resistors (we run out of 100 Om chip resistors.)
(5) I wrapped the OSEM flags by plastic tubes to block the light from the LED more efficiently. This also removed
the changes of the photocurrent in the photodetector when the levitated plate moves horizontally.
Possible issues that cause the setup not working at the moment:
(1) The feedback gain could be probably still not enough. During the experiment, I can't feel any force changes when the
flags crossing the zero point. The error signals and control signal has the right sign.
(2) The levitated weight may be not enough and the working point is below the extremum of the DC attracting force.
This could give rise to a large negative spring which requires unreasonable feedback gain to compensate.
(3) The DC attracting force between the magnets are differing each other too much (mismatch) and can't
be compensated by the coil driving force.
(4) The control bandwidth may be still not large enough. Initially my design was 100 Hz, but I forgot to divide
the angular frequency by 2pi and the resulting circuit has a bandwidth of 20 Hz. Later I increase it up to 80 Hz
by changing the resistors as mentioned before.
(5) The polarization of the coil could have a wrong sign. I have checked with Gauss meter, but still the absence
of zero-point crossing force change makes me worry about this.
For continuation of this work, I will finish writing my document and summarize all the results and outline what
needs to be done in the future. If everything goes well, I will be back in June and can spend more time on this
experiment. I can also work with the summer students together on this project.
The far right monitor in the control room is now displaying IMCR, PMCT, RCR, RCT.
Please note that top left quad is displying PMCT even if the screen is labeled with PMCR.
Control room monitor #13 - #16 had been out of order since the last week.
(the monitor number is shown at : http://lhocds.ligo-wa.caltech.edu:8000/40m/Electronics/VideoMUX )
I found that the connections between camera and the cable to the VIDEO MUX were missing so I connected them.
Initially, PMCT camera was sending its signal to the small monitor on the PSL table.
I splitted the signal so that one signal is going to the small monitor and another is going to the VIDEO MUX.
The "PMCR" is shown on the screen #13 in the control room but it actually showing PMCT camera's signal.
This is a temporary VIDEO configuration. It will be upgraded as well when the whole VIDEO will be upgraded.
I discovered that somehow my Wiener filters that show up in Foton are not the same as what I have in Matlab-land.
I have plotted each of my 3 filters that I'm working with right now (T-240 X, Y and Z for PRCL Pitch) at several stages in the filter creation process. Each plot has:
It's not just a DC gain issue - there's a frequency dependent difference between these filters. Why??
It's not frequency warping from changing between analog and digital filters. The sample rate for the OAF model is 2048Hz, so the effect is small down at low frequencies. Also, the green trace is already discretized, so if it were freq warping, we'd see it in the green as well as red, which clearly we don't.
Has anyone seen this before? I'm emailing my seismic friends who deal in quack more than I do (BLantz and JKissel, in particular) to see if they have any thoughts.
Also, while I'm asking questions, can autoquack clear filters? Right now I'm overwriting old filters with zpk(,,1)'s, which isn't quite the same. (I need this because the Wiener code needs more than one filter module to fit all of the poles I need, and it decides for itself how many FMs it needs by comparing the length of the poles vector with 20. If one iteration needs 4 filter modules, but the next iteration only wants 3, I don't want to leave in a bogus 4th filter.
Here are the plots:
(The giant peak at ~35Hz in the Z-axis fiilter is what tipped me off that something funny was going on)
I got some QPR Nitrile gloves. They are LIGO approved.White nitrile gloves are naturally anti-static- 109 ohms
Their touch not as good as laytex gloves but try to use them.
I removed the dumps in front of the trans QPDs. The Yend QPD needed re-normalization, so I did that.
If Rob/Yoichi say the alignment is now good, the we absolutely must center the IOO QPDs and IP POS and IP ANG and MC TRANS today so that we have good references.
IOO_QPD_POS, IOO_QPD_ANG, MC_TRANS, IP_POS, IP_ANG have all been centered.
Also, the MCWFS have been centered.
I'm now working on making sure beam is hitting all of the RF PDs around.
I built the summing/subtracting circuit on the breadboard, and hooked this up with one of the other QPDs I found (image of setup attached). I wasn't able to get this to read the correct signals when testing with a laser pointer after a couple of hours of troubleshooting... I will hopefully get this working in the next day or 2...
I'm going to read up on ECDL stuff for Tara tonight and hopefully figure out what sort of laser diode we should purchase, since I'm meeting with Tara tomorrow. experimenting
All of the QPDX matrix fields had a missing underscore in them. So I committed all of the c1asc screens to the SVN (because no one but me and Jamie seems to be able to remember to do this).
Then I did find/replace on the QPDY screen and saved it over the QPDX screen and committed the new thing to SVN as well. Values are now accessible.
Yesterday I installed teh QPD on the table behind MC2, and observed teh signal on it.
The MC_leak is directed to it by a steering mirror.
I used the A2L_MC2 script to minimise teh pitch and yaw gains, and estimated teh spot position on teh MC2 using that.
This spot position was aligned to the center of teh QPD.
In the night while before taking measurements, I decided to turn off the Wavefront Sensor Servos, but just after that, the MC alignment went very bad, and I could not align it in the next 2 hours.
For some reason, the MC was really mad the whole day yesterday, and was getting misaligned again and again, even when the WFS feedback was on.
The table also had another IR laser in it, which I and Koji switched off.
I will continue measuring once we pump down again.
For now, I am analysing teh QPD circuit Transfer Function.
I have changed all of the oplevs and transmon QPDs to use the common ISC QPD library block, which differs mainly in its divide by zero protection.
c1scx.mdl and c1scy.mdl were directly changed for the transmon QPDs. The oplevs were done by changing the sus_single_control.mdl library part, which is used for all of the SOSs.
Then, because of the underscore introduced (i.e. OLPIT becomes OL_PIT because there is an OL block), I went on a sed safari to find and replace the new channel names into:
I've fixed everything that occured to me, and the usual ways I'm used to interacting with the oplevs all seem to work at this time, but it's entirely possible I've overlooked something.
One important note is: because we are now using an effectively immutable QPD library block, the oplev urad conversion has to take place in the DoF matrix. The EPICS records C1:SUS-[OPTIC]_OL_[DOF]_CALIB still exist, but do not multiply the fast signals. Rather, the OL_MTRX elements are multiples of the CALIB value. I thought about making a new QPD_CALIBRATED part or something, but then we're right back to using custom code, which is what we're trying to avoid.
All of the oplev DoFs are stable, I checked a few loop TFs like ETMY pitch and PRM yaw, and they looked normal.
Might have to also get the OL screens that go with this new code to see, but the calibrations don't go into the matrix, but rather into the OLPIT/OLYAW filter banks which follow the division, but before the servo filter banks.
I fiddled around with the QPD that I'll use to replace Koji's temporary razor blade yaw sensor for detecting POP beam angular motion, and checked that it is working.
Using the Jenne Laser, I put beam onto the 4 different quadrants of the QPD, and saw that the Sum channel remained constant.
* I had the room lights off, since the PD elements are silicon.
* Beam size on the QPD as seen on an IR card was ~1mm diameter.
* With the beam on the QPD, I chose gain setting "G2" on the amplifier, since that was the only setting where neither the "current too high" nor the "current too low" LEDs were illuminated. I didn't measure the power going to the PD, but the Jenne Laser puts out 1.2mW, and there's a 50/50 BS, so I was getting about 600uW.
* I turned off the "zero/cal" switch on the back of the box, since I don't know how to set the zero. Since the X and Y channels are normalized by the Sum, you can't just block all light going to the PD and set the zero. There isn't a big change in the output levels with the zero/cal switch off, so I think it should be fine. (Previously, I set all 4 knobs - "zero" and "cal" for each X and Y - to approximately the center of their ranges. Once you hit the end of the range, you can keep turning the knob, but something inside makes a clicking sound ~once per revolution, and the signal level stops changing (for the zero knobs). Much like centering a beam on a PD, I found each edge of the range for each knob, and set the knobs in the centers by counting the number of turns. Anyhow, since I set the knobs to ~halfway, I think that explains why there isn't really a change whether the "zero/cal" switch is on or off.
* Using the steering mirror sending the beam to the QPD, I moved the beam around, and watched where I was going with an IR viewer. I see that as I move from quad-to-quad, the X and Y channels respond as I expect. If I only move the beam in X, I only see X response on a 'scope, and vice versa.
I can't do a real calibration until I get the QPD installed in place, so I can use the actual beam, but for now it looks like the QPD is responding nicely. Since Annalisa and Manasa are using the Arms for the evening, I'll work on putting the QPD on the POX table tomorrow.
I have put beam dumps in front of both of the end transmission QPDs so that I could measure the dark noise. They are still there.
I checked that the Yend QPD sliders and switches were doing things as I expected. I couldn't do the Xend since c1auxex is still lost (elog 10165). I'll post plots and actual information on this checkout, as well as my calculation of what this dark noise means in terms of meters for CARM when we're using 1/sqrt(trans) signals tomorrow morning.
Measurement of Yend transmission QPD dark noise
Since EricQ had already checked out the whitening filters (see elog 9637 and elog 9642), I didn't check on them. I just left them (the analog whitening, and the digital antiwhitening filters) on.
First, I checked the noise vs. transimpedance gain. There are a few too many settings to put them all on one plot, so I have them sorted by the original transimpedance: 0.5 kOhms vs 5 kOhms. It's a little tricky to see, but all of the spectra that begin with the 5k transimpedance have a little extra noise around 10 Hz, although I don't know why. In the legend I have made note of what the settings were. x1 x1 is my representation of the "inactive" setting.
I then looked at the noise with different whitening gain slider settings. All but one of the traces are the 20 kOhm setting.
These .xml files are in /users/jenne/Arms/TransQPDnoise_July2014/
Calculation of inverse sqrt transmission sensitivity
I used Optickle to give me the power transmitted through the ETMs. I first find the transmission in the FPMI case. I use that to normalize the full PRFPMI transmission, so that the output units are the same as our C1:LSC-TR[x,y]_OUT units.
I take the square root of the transmitted power (sum of transmissions from each arm) at each CARM offset point, add 1e-3 as we do in the front end model to prevent divide-by-zero problems, and then take the inverse.
I find the slope by taking the difference in power between adjacent points, divided by the CARM offset difference between those points.
In this plot, I have taken the absolute value of the sensitivity, just for kicks. I also display an arbitrarily scaled version of the log of the transmitted power, so that we can see that the highest sensitivity is at half the maximum power.
Calculate the QPD dark noise in terms of meters
Finally, I put it all together, and find the dark noise of the QPD in terms of meters. Since the spectra were measured in units where the single-arm transmission is unity, the already match the units that I used to calculate the sqrtInv sensitivity.
I take the spectra of the QPD dark noise for the 20 kOhm case, and multiply it by the sensitivity calibration number at several different CARM offsets. As we expect, the noise is the best at half-max transmission, where the sensitivity is maximal.
I spent awhile today reading about op-amps and understanding what would be necessary to design a circuit which would directly give pitch and yaw of the QPD I am using. After getting an idea of what signals would be summed or subtracted, I opened up the QPD to take better pictures than last time (sorry, the pictures were blurry last time and I didn't realize). It turns out some of the connections have been broken inside the QPD, which would explain why we saw an unchanging signal in Ch2 on the oscilloscope yesterday when trying to test the laser setup.
I found a couple other QPDs, which I will be using to help understand the circuit (and what is going on). I will be trying to use the same QPD box since it has banana cable and BNC cable adapters, which is helpful to have in the lab. Once I have concluded what the circuitry is like and designed electronics to add and subtract signals, I will build and mount all the circuits within the box (more sturdily than last time) so as to have a quality way of measuring the mount vibrations when I get there.
I took better pictures of the circuits of the QPD and spent a couple of hours with a multimeter trying to figure out how all the connections worked. I will continue to do so and analyze the circuits over the weekend to try to understand what is going on. I also have an old SURF report that Eric sent me that is similar to the design I was planning to use to sum the pitch and yaw signals. I will try and look at this over the weekend.
Today I tested the circuitry within the QPD to make sure I had put it back together correctly. The output was able to detect when a laser pointer was shone on different quadrants of the QPD when hooked up to the oscilloscope, so fixing the QPD worked!
Following this, I spent awhile understanding what was going on with the circuit reading from the QPD. I concluded that the opamp on the QPD circuit acted as a low pass filter, with corner frequency of about 17 kHz, which serves our purposes (we are only interested in frequencies below 1 kHz). I diagrammed the circuit that I plan to build to give pitch and yaw (attached). It will be necessary to make small modifications to the circuitry already built (removing some resistors), which I have started on.
Next time, I will construct the circuit that adds/subtracts signals on a breadboard and test it with the QPD circuit that is already built.
[ Yuki, Gautam, Steve ]
I calibrated a QPD (D1600079, V1009) and made sure it performes well. The calibration constants are as follows:
X-Axis: 584 mV/mm
Y-Axis: 588 mV/mm
The calibration of QPD is needed to calibrate steeing PZT mirrors. It was measured by moving QPD on a translation stage. The QPD was connected to its amplifier (D1700110-v1) and +-18V was supplied from DC power supplier. The amplifier has three output ports; Pitch, Yaw, and Sum. I did the calibration as follows:
The results are attached. The main signal was fitted with error function and I drawed a slope at zero crossing point, which is calibration factor. I determined the linear range of the QPD to be when the output was in range -50V to 50V, then corresponding displacement range is about 0.2 mm width. Using this result, the PZT mirrors will be calibrated in linear range of the QPD tomorrow.
previous experiment by Gautam for X-arm: elog:40m/8873, elog:40m/8884
I assume this QPD set is a D1600079/D1600273 combo.
How much was the SUM output during the measurement? Also how much were the beam radii of this beam (from the error func fittings)?
Then the calibration [V/m] is going to be the linear/inv-linear function of the incident power and the beam radus.
You mean the linear range is +/-50mV (for a given beam), I guess.
Then the calibration factor of the QPD is
X axis: 584 * (POWER / 2.96mW) * (0.472mm / RADIUS) [mV/mm]
Y axis: 588 * (POWER / 2.96mW) * (0.472mm / RADIUS) [mV/mm].
The voltage regulator on the QPD breadboard seems to be having problems... yesterday Eric helped me debug my circuit and discovered that the +12V regulator was overheating, so we replaced it. Today, I found that the -12V regulator was also doing the same thing, so I replaced it. However, it's still overheating. We checked all of the setup for the power regulators yesterday, so I'm not sure what's wrong.
I've also noticed that not all the connections on the breadboard that I've been using seem to work - I may search for a new breadboard in this case. Need to check I'm not doing something stupid with that.
Breadboards may not be suitable for a reliable work. Why don't you switch to any protoboard and real soldering?
Friday night myself and Koji measured the Transfer function of the QPD circuit at MC2 side using a chopper . Following was our procedure :
We connected some wires at the input and output of the filter circuit to one of the segment of teh QPD. - seg 1.
A laser light was shined on to the QPD, it was pulsed using a chopper. The frequency of rotation of the chopper was varied.
These wires were then fed to the spectum analyser , and a transfer funstion was observed, It was nearly a low pass filter
The chopper frequency was then made variable by giving the chopper a signal from the spectrum analyser. This signal just swiped a large range of the rpm of the chopper.
Now the input signal looked like a sine wave of varying frequency. the transfer function looked like a perfect LPF, with a small SNR.
Attaching the plot of the TF in the next e-log (this one is on windows and can't access /cvs/cds)
We connected some wires at the input and output of teh filter circuit to one of the segment of teh QPD. - seg 2.
A laser light was shined on to the QPD, it was pulsed using a chopper. The frequency of rotation of teh chopper was varied.
The chopper frequency was then made variable by giving the chopper a signal from teh spectrum analyser. This signal just swiped a large range of the rpm of the chopper.
Now the input signal looked like a sine wave of varying frequency. the transfer functino looked like a perfect LPF, with a small SNR.
Attaching the plot of the TF in the next e-log (this one is on windows and cant access /cvs/cds)
Koji and I had noticed that there was some discrepancy between the switchable gain stages of the EX and EY QPDs. Sadly, there was no indication that these switches even exist on the QPD MEDM screen. Yehonathan and I rectified this today. Both EX and EY Transmon QPDs now have some extra info (see Attachment #1). We physically verified the indicated quadrant mapping for the EX QPD (see previous elog in this thread for the details), and I edited the screen accordingly. EY QPD still has to be checked. Note also that there is an ND=0.4 + ND=0.2 filter and some kind of 1064nm light filter installed in series on the EX QPD. The ND filters have a net transmission T~25%.
After making the EX and EY QPDs have the same switchable gain settings (I also reset the trans normalization gains), the angular motion witnessed is much more consistent between the two now - see Attachment #2. The high-frequency noise of the sum channel is somewhat higher for EX than EY - maybe the ND filters are different on the two ends?
Note that there was an extra factor of 40 gain on the EX QPD relative to EY during the lock yesterday. So really, the signals were probably just getting saturated. Now that the gains are consistent between the ends, it'll be interesting to see how balanced the buildup of the two arms is. There still remains the problem that the MICH loop was too unstable, which probably led to to excess arm power fluctuations.
There is a mark on the QPD surface that is probably dirt (since we never have such high power transmitted through the ETM to damage the QPD). I'll try cleaning it up at the next opportunity.
In search of the source of discrepancy between the QPD readings in the X and Y arms, we look into the schematics of the QPD amplifier - DCC #D990272.
We find that there are 4 gain switches with the following gain characteristics (The 40m QPD whitening board has an additional gain of 4.5):
Switch 4 bypasses the amps controlled by switch 2 and 3 when it is set to 1 so they don't matter in this state.
Note that according to elog-13965 the switches are controlled through the QPD whitening board by a XT1111a Acromag whose normal state is 1.
Also, according to the QPD amplifier schematics, the resistor on the transimpedance, controlled by switch 1, is 25kOhm. However, according to the EPICS it is actually 5kOhm. We verify this by shining the QPD with uniform light from a flashlight and switching switch1 on and off while measuring the voltages of the different segments. The schematics should be updated on the DCC.
Surprisingly, QPDX switches where 0,0,0,0 while QPDY switches where 1,0,0,1. This explains the difference in their responses.
We check by shining a laser pointer with a known power on the different segments of QPDX that we get the expected number of counts on the ADC and that the response of the different segments is equal.
I have sketched out the circuit design for the QPD. However, it seems like even when using a different opamp configuration, which I talked to Eric about on Friday, space will be a problem. It may be possible to squeeze everything onto a single circuit board to fit in the QPD box but what I think is more likely is that I will need to have 2 separate circuit boards both mounted within the box, one which integrates the signal from the QPD and the other which adds/subtracts (this involves many resistors which will take up a lot of space). I will continue to think about the best design for this.
I will try to have the circuit built in the next week or so, which may be difficult since I just started finals which will take most of my time. I spent most of this week writing up an ECDL proposal for a SURF with Tara. I'll make up for whatever work I miss since I'll be here for my spring break and doing little besides working in lab.
I finished working out the circuit and figured out where the broken connections were. This is diagrammed in my notebook (will draw up more nicely and include in future elog post). Within the QPD circuitry, it seems like there are already opamps which regulate the circuit. I need to discuss the final diagram further with Eric.
I rewired the circuit inside the QPD box, which took awhile because it was difficult to solder the wires to such small locations without having multiple wires touch. This is completed, and on Friday I will begin to make the circuit to add/subtract signals to give pitch and yaw.
I corrected the circuit diagram I constructed last time - it would read 0 output most of the time because I made a mistake with the op amps. This will be attached once I discuss it with Eric.
I searched the 40m lab and ended up finding a breadboard in the Bridge lab. I then spent awhile trying to remove the QPD from the circuit board it was on, which was difficult since it had 6 pins. After that, I soldered wires to the QPD legs and began constructing the circuit on the breadboard. I also spent time showing Annalisa the setup and explaining my project.
On Friday I will try and reconstruct all of the circuitry from before for the QPD.
In order to test the mount vibrations, I will likely try and make a different circuit work (with the summing/subtracting on an external breadboard) and designing an optimal circuit will be a side project. This is the circuit with the power supply Rana came up with, and the design I had in mind for the rest of the circuit. In my free time, I will try to figure out what parts to get that reduce noise and slowly work on building this, since it would be useful to have in the lab.