Measuring POX11_Q_MON and injecting a signal into the ITMX_UL_IN port a signal could not be seen on the function generator. After debugging the source of the issue was two fold:
Unrelated to these issues the signal input was switched to POY11_Q_MON and ITMY_POS_IN as part of the debugging process. The function generator used was switched from the Stanford to the Siglant SDG 1032X.
An unrelated issue but note worthy was the Lenovo 40m laptop used to measure the IFO state (locked or unlocked) ran out of battery in a very short timespan.
To gauge where the resonance of the test masses are FEA model of a simple 40m test mass was computed to give an esitimate at what frequency the eigenmodes exist. For the first two modes the model gave resonances at 20.366 kHz (butterfly mode) and 28.820 kHz (drumhead mode). Then by measuring with an acquisition time of 1 s at they frequencies on the SR785 and injecting broad band white noise with a mean of 0 V and a stdev of 2 V, small peaks were seen above the noise at 20.260 kHz and 28.846 kHz. By then injecting a sine wave at those frequencies with 9 Vpp, the peak became clearly visible above the noise floor.
The last step is to measure the natural decay of these modes when the excitation is turned off. It is difficult to tell currently if these are indeed eigenmodes or just large cavity injections with an associated stabilisation time (what could appear as a ringdown decay). More investigation is required.
We took measurements of the Q of all the modes that we could think of for TT#4, and then repeated several of the same measurements for TT#2. We noticed that when we took off the backplane and then replaced it on TT#4, the pitch pointing had changed, so we had to repeat the balancing procedure by slightly shifting the position of the wire clamps relative to the mirror holder. No fun. We decided to quit removing the backplanes.
The main conclusion of this evening's measurements of TT#4 is that everything looks very close to the design ideas. Good work team!
'Free Swinging' values (just for interest)
Vert, no damping: Q = 31.4
Pitch, no damping (ECD backplane removed): Q = ~700
Yaw, no ECDs: Q = ~900
Pos, no ECDs (no measurement) - we had already put the backplane back on, and didn't want to take it off again.
Vert, with damping: Q = 14.3
Pitch, with ECDs: overdamped, so Q < 1/2
Yaw, with ECDs: Q = 2.3
Pos, with ECDs: Q = 1.4
Side, with ECDs: Q = 1.9
We also measured the resonant frequency of each of the ECDs for this TT (since we had the backplane removed anyway...)
ECD UL: 10.05Hz
ECD UR: 10.15Hz
ECD LL: 10.21Hz
ECD LR: 10.21Hz
Yaw, with ECDs: Q = 7.0
Vert: Problematic. No damping, f = 25.9Hz, Q = 36. With rubber dampers, f = 20.0Hz, Q = 42. Yes, you read that right. The frequency is lower, and the Q is higher *with* the damping. Perhaps our brains are fried. Perhaps we've discovered new, inconsistent physics (awfully unlikely....). We'll revisit this again tomorrow to figure out what mistake we're making.
We need MC to be locked soon, so MC suspensions should be damped well(Q~5).
What I did:
1. Set the correct filters and turn all the damping servo on.
2. Kick the optics by adding some offset into the control loop.
3. Measure the Q-value of the ringdown with my eye.
4. If Q-value seems to be around 5, go to step #5. If not, change the filter gain and go to step #2.
5. Done! Do step #1-4 for all MCs.
All parameters I used for the servo are automatically saved here;
Q-values of the damping servo for all MCs are set to around 5.
Attached is the ringdown of MC2 for example.
As you can see, my eye was very rough......
- Make a script that does steps #2-5 automatically.
I need pyNDS module installed to get data using Python.
I already wrote the rest of the script.
We'll have Leo help us install pyNDS tomorrow.
Last week and this week I've been working on the characterization of the Q3000 QPDs. The QPDs were named 81, 82, 83, and 94.
My recommendation is to use #81 and #84 as they have similar dark current characteristics between the segments. But basically, all the QPDs look fine.
The actual junction capacitance and the RF dark noise should be characterized by the actual WFS head circuit.
The QPD packages were labeled and returned to Gautam to be implemented in the WFS heads.
gautam: S/N #84 was installed as the AS WFS QPD. The remaining 3 are stored in the clean cabinet at EX (where the rest of the RF photodiodes are).
Because we would like to get started on testing mount vibrations as soon as possible, I've been trying to get one of the other QPDs we found to work with the summing/subtracting circuit on a breadboard. I've been using a power supply that I think Jamie built 15 years ago... which seems to be broken as of today, since I no longer read any signal from it with an oscilloscope.
I tried using a different power supply, but I still can't read any change in signal with the QPD for any of the quadrants when using a laser pointer to shine light on it. I'll be working with Eric on this later this week. In the meantime, I'll try and come up with a shopping list for the nicer QPD circuit that'll be a longer term side project.
Annalisa and I met yesterday and fixed the voltage regulator on the breadboard so the QPD circuit is working. We will meet with Eric on Thursday to determine the course of action with measurements.
I've remeasured the QPD ASC sensing coefficients, and figured out what I did weird with the actuation coefficients. I've rearranged the controller filters to be able to turn on the boost in a triggered way, and written Up/Down scripts that I've tested numerous times, and Jenne has used as well; they are exposed on the ASC screen.
All four loops (2 arms * pit,yaw), have their gains set for 8Hz UGF, and have 60 degrees of phase margin. The loop shape is the same as the previous ELOG post. Here is the current on/off performance. The PDH signals (not shown, but in attached xml) show no extra noise, and the low frequency RIN goes down a bit, whic is good. The oplevs error signals are a bit noisier, but I suppose that's unavoidable. The Y-arm performs a bit better than the X-arm.
The up/down scripts don't touch the filters' trigger settings at all, just handles switching the input and output and clearing history. FM1 contains the boost which is intended to have a longer trigger delay than the filters themselves.
As mentioned in a previous ELOG, in single arm lock, I measured the QPD response with respect to the calibrated oplev signals. They were:
ETMY: QPD PIT / OPLEV PIT = 22.0 count/urad
QPD YAW / OPLEV YAW = 17.1 count/urad
ITMY: QPD PIT / OPLEV PIT = -6.0 count/urad
QPD YAW / OPLEV YAW = 5.9 count/urad
ETMX: QPD PIT / OPLEV PIT = 16.6 count/urad
QPD YAW / OPLEV YAW = -9.3 count/urad
ITMX: QPD PIT / OPLEV PIT = 4.0 count/urad
QPD YAW / OPLEV YAW = -6.0 count/urad
For reference, one microradian of either ITM or ETM motion produces about 60um of ETM beam spot displacement, compared to the spot size of ~5mm.
However, given the lenses on the end tables that are used for green mode matching, that the IR transmitted beam also passes through, the QPDs are not directly imaging the ETM spot position; if they were, they would have equal sensitivity to ITM and ETM motion due to our flat/curved arm geometry.
From this data, I calculated the actuation coefficients for each DoF as , and similarly for the ITMs, where the d's come from the table above. However, it occurs to me that maybe this isn't the way to go... I'll mention this later.
Up until now, at every turn, I had not properly been thinking about how the oplev loop plays into all of this. I went to the foton filters, and grabbed the loop and plant models for the ETMY oplev, and constructed the closed loop gain, 1/1+G, and the modified plant, P/1+G, which is what the ASC loop sees as its plant.
Here, the purple trace explains all of the features I was confused about earlier.
With this in hand, I set up to design a loop to satisfy our motivations.
To do this, I inverted the oplev closed loop plant pole around 4Hz to smooth the whole thing out. Here's a comparison of the measured OLG with what I modelled.
There's a little bit of phase discrepency around 10Hz, but I think it looks about right overall.
So, here's the part that counts: How does this actually perform? I took spectra of the QPD error signals, the relevant OpLev signals as out of loop sensors, the PDH error signal and transmitted RIN while single arm locked, with this loop off, and on for all 4 DoFs simultaneously.
This is what makes me think I may need to revisit the actuation matrix. If I did it wrong, I am driving the "invisible" quadrant of the cavity angular DoFs, and this could be what is injecting noise into the oplevs.
In the end, I have a better understanding of what is going on, and I don't think we're quite there yet.
Although the QPD loops are less than ideal right now, I made changes to the ASC model to trigger the QPD loops on and off politely, depending on TRX and TRY. The settings are exposed on the ASC screen. However, I have not yet exposed the FM triggering that I also set up to make sure the integrator doesn't misbehave if the arm loses lock. We probably don't want to trigger them on at anything lower than arm powers of about 1.0.
I've tested the triggering by randomly turning LSC mode on and off, and making sure that the optics don't recieve much of a kick as the QPD loops engage a few seconds after the LSC boosts do, or when lock is lost. This works as long as there isn't much of a DC offset befire the loops are engaged. (Under 20 counts or so is fine)
As a side note, I was going to use the TRIG_SIG signals sent via the LSC model via SHMEM blocks for the ASC triggering, but oddly, the data streams that made it over were actually the MICH and SRCL TRIG_SIGs, instead of XARM and YARM as labelled. I double checked the simulink diagrams; everything seemed fine to me. In any case, ASS was already recieving TRX and TRY directly via RFM, so I just piped those over to the ASC block. This way is probably better anyways, because it directly references the arm powers, instead of the less obvious LSC triggering matrix.
Today I finished building the adding/subtracting circuit for the QPD and tested that the QPD could see a laser moving across its visual field for both pitch and yaw. It didn't seem to behave weirdly (saturate) at the edges, but I need to test this more carefully to be sure.
However, this circuit uses many op amps, which will cause problems for building the actual circuit to fit into the QPD box. I am trying to figure out how to do this with fewer op amps (both with a quad op amp for amplifying the signals from the QPD and by summing/subtracting the signals with a single op amp instead of 3).
I finally got around to asking Steve to order more breadboards! Trying to determine what would be a good QPD to order for the final circuit, since we do not have any unmounted QPDs that aren't ancient. I'll read up on things I don't know enough about (namely op amps).
I have been working on setting up a QPD which can eventually be used to calibrate the PZT, and also orient the PZT in the mount such that the pitch and yaw axes roughly coincide with the vertical and horizontal.
The calibration constants have been determined to be:
X-axis: -3.69 V/mm
I initially tried using the QPD setup left behind by Chloe near MC2, but this turned out to be dysfunctional. On opening out the QPD, I found that the internal circuitry had some issues (shorts in the wrong places etc.) Fortunately, Steve was able to hand me another working unit. For future reference, there are a bunch of old QPDs which I assume are functional in the cabinet marked 'Old PDs' along the Y-arm.
I then made a circuit with which to read out the X and Y coordinates from the QPD. This consists of 4 buffer amplifiers (one for each quadrant), and 3 summing amplifiers (outputs are A+B+C+D = sum, B+C-A-D = Y-coordinate, and A+B-C-D = X-coordinate) that take the appropriate linear combinations of the 4 quadrants to output a voltage that may be calibrated against displacement of the QPD.
The output from the QPD is via a sub-D connector on the side of the pomona box enclosing the PD and the circuitry, with 7 pins- 3 for power lines, and 4 for the 4 quadrants of the QPD. It was a little tricky to figure the pin-out for this connector, as there was no way to use continuity checking to map the pins to quadrants. Therefore, I used a laser pointer, and some trial and error (i.e. shine the light on a given quadrant, and check the sign of the X and Y voltages on an oscilloscope) to map the pin outs. Steve tells me that these QPDs were made long before colour code standardisation, but I note here the pin outs in any case for future reference (the quadrant orientations are w.r.t the QPD held with all the circuitry above it, with the active surface facing me):
Green = GND
Blue = Upper Left Quadrant
White = Upper Right Quadrant
Purple = Lower Left Quadrant
Grey = Lower Right Quadrant
Chloe had noted that there was some issue with the voltage regulators on her circuit (overheating) but I suspect this may have been due to the faulty internal circuitry. Also, she had used 12 V regulators. I checked the datasheet of the QPD, Op-Amp LF347 (inside the pomona box) and the OP27s on my circuit, and found that they all had absolute maximum ratings above 18V, so I used 15V voltage regulators. The overheating problem was not a problem anymore.
I then proceeded to arrange a set up for the calibration (initially on the optical bench next to MC2, but now relocated to the SP table, and a cart adjacent to it). It consists of the following:
Having set everything up and having done the coarse alignment using the mirror mount, I proceeded to calibrate the X and Y axes of the QPD using the translational stage. The steps I followed were:
The plots are attached, from which the calibration values cited above are deduced. The linear fits for the orthogonal axis were done using cftool. There is some residual coupling between the X and Y motions of the QPD, but I think this os okay my purposes.
My next step would be to first tweak the orientation of the PZT in the mount while applying a small excitation to it in order to decouple the pitch and yaw motion as best as possible. Once this is done, I can go ahead and calibrate the angular motion of the PZT in mrad/V.
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.
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.
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.
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.
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)
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?
[ 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].
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.
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.
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 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 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 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.
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.
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.
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
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 removed the dumps in front of the trans QPDs. The Yend QPD needed re-normalization, so I did that.
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 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)
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 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.
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
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.