40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 197 of 341  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  3303   Tue Jul 27 23:46:45 2010 JenneUpdateSUSQ measurements of 2 TTs

[Koji, Jenne]

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!

TT#4:

'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.

 

Damped Values:

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

 

TT#2:

Yaw, with ECDs: Q = 7.0

Pitch, with ECDs: overdamped, so Q < 1/2

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.

  3710   Thu Oct 14 00:04:46 2010 yutaUpdateSUSQ-value adjustment for MC dampings

Background:
 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;
  /cvs/cds/caltech/burt/autoburt/snapshots/2010/Oct/13/20:07/c1mcs.epics

Result:
 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......

Next work:
 - 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.

Attachment 1: MC2ringdown.png
MC2ringdown.png
  15687   Mon Nov 23 23:27:43 2020 KojiSummaryASCQ3000 characterization

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.

  • Dark current [OMC LAB ELOG 402]: All the segments looked similar and acceptable except for the seg1 of #82. It has a smaller reverse breakdown voltage (~6V) but even this is an acceptable level.
  • Impedance [OMC LAB ELOG 403]: All the segments showed a ~300pF junction capacitance with no reverse bias. This looks quite normal.
  • Dark noise [OMC LAB ELOG 404]: All the segments showed ~5pA/rtHz dark noise above 1Hz.

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).

  8381   Mon Apr 1 16:13:50 2013 ChloeUpdate QPD

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.

  8511   Tue Apr 30 12:25:23 2013 ChloeUpdate QPD

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.

  10997   Tue Feb 10 18:37:17 2015 ericqUpdateASCQPD ASC ready to go

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.

Attachment 1: Feb10_loops_offOn.png
Feb10_loops_offOn.png
Attachment 2: Feb10_newLoops_offOn.xml.zip
  10920   Mon Jan 19 18:27:16 2015 ericqUpdateASCQPD ASC saga continues.

Herein, I will try to paint a more thorough picture of this whole QPD ASC mess. 


Motivation for QPD ASC loops:

  • We would like to use the QPDs as a DC arm pointing reference during locking attempts, or over multiple days, if possible. 
  • It would be nice if the QPDs could complement the oplevs to reduce angular motion of the cavity. 
  • We must not make the single arm longnitudinal noise or RIN worse, because anything observable in the single arm case will be catastrophic at full sensitivity

Actuation design:

As mentioned in a previous ELOG, in single arm lock, I measured the QPD response with respect to the calibrated oplev signals. They were:

YARM
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
XARM
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 A_{ETM} = \frac{d_{ETM}}{\sqrt {d_{ETM}^2 + d_{ITM}^2}}, 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. 


Loop design:

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. 

  • Bounce/roll mode notches to avoid exciting them
  • 1/f UGF crossing at a few Hz, limited by the gain margin at ~10Hz, which is where the phase will hit 180, due to the notches
  • 4th order Elliptic lowpass at 100, to avoid contaminating the longnitudinal signals
  • 1/f^2 at low frequencies for DC gain

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. 


Evaluation:

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. 

Verdict:

  • In-loop signals get small, unsurprisingly.
  • Cavity signals unchanged. yes
  • ITM oplev signals are unchanged (and not plotted, to not clutter the plots (This isn't surprising since the loops mostly actuate on the ETMs).
  • ETM oplev signals get smaller around the 3Hz peak, but are louder in other bands.no 

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. 


Conclusion:

In the end, I have a better understanding of what is going on, and I don't think we're quite there yet.  

Attachment 1: oplevPlant.pdf
oplevPlant.pdf
Attachment 2: loopDesignComparison.pdf
loopDesignComparison.pdf
  10921   Tue Jan 20 02:39:49 2015 ericqUpdateASCQPD ASC saga continues.

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. 

  8233   Tue Mar 5 17:23:06 2013 ChloeUpdate QPD Adding/Subtracting Circuit

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).

  8873   Thu Jul 18 19:09:08 2013 gautamConfigurationendtable upgradeQPD Calibration for PZT Calibration

Summary 

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

Y-axis: -3.70V/mm

Methodology:

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):

Red= +Vcc

Black= -Vcc

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:

  • He-Ne laser source
  • Y2 2-inch mirror (AR and HR coated for 532nm) glued onto the PZT and mounted on a machined Newport U100P  - see this elog for details.
  • QPD mounted on a translational stage whose micrometers are calibrated in tenths of an inch (in the plots I have scaled this to mm)
  • A neutral density filter (ND = 2.0) which I added so that the QPD amplifier output did not saturate. I considered using a lens as well to reduce the spot size on the QPD but found that after adding the ND filter, it was reasonably small.
  • High-voltage power supply (on cart)
  • Two SR power supplies (for the PZT driver board and my QPD amplifier
  • SR function generator
  • Laser power source
  • Two oscilloscopes
  • Breadboard holding my QPD amplifier circuit

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:

  • Centre spot on QPD using coarse adjustment on the mirror mount: I gauged this by monitoring the X and Y voltage outputs on an oscilloscope, and adjusted things till both these went to zero.
  • Used the tilt knob on the translational stage to roughly decouple the X and Y motion of the QPD.
  • Kept Y-coordinate fixed, took the X-coordinate to close to its maximum value (I gauged this by checking where the voltage stopped changing appreciably for changes in the QPD position.
  • Using this as a starting point, I moved the QPD through its X range, noting voltage output of the X-coordinate (and also the Y) on an oscilloscope.
  • Repeated the procedure for the Y-coordinate.
  • Analysis follows largely what was done in these elogs. I am attaching the script I used to fit an error function to the datapoints, this is something MATLAB should seriously include in cftool (note that it is VERY sensitive to the initial guess. I had to do quite a bit of guessing).

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.

 

                                                            X-Axis                                                                                                                                Y-axis                                                

QPD-XCalib.pdf  QPD-YCalib.pdf

 

 

Attachment 3: Error_Function_Fitting.zip
  8111   Tue Feb 19 17:14:56 2013 ChloeUpdate QPD Circuit

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.

  8173   Tue Feb 26 17:36:28 2013 ChloeUpdate QPD Circuit

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.

  8346   Mon Mar 25 23:27:26 2013 ChloeUpdate QPD Circuit

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. 

 https://www.circuitlab.com/circuit/7sx995/qpd-circuit/#postsave_access_control_settings

  8295   Thu Mar 14 16:56:16 2013 ChloeUpdate QPD Circuit Design

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.

  15039   Wed Nov 20 17:20:24 2019 YehonathanUpdateLSCQPD Investigation

{Gautam, Yehonathan}

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):

S4 S3 S2 S1 V/A
0 0 0 0 2e4
0 0 0 1 2e5
0 0 1 0 4e4
0 0 1 1 4e5
0 1 0 0 1e5
0 1 0 1 1e6
0 1 1 0 2e5
0 1 1 1 2e6
1     0 5e2
1     1 5e3

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.
 

gautam edits:

  1. Lest there be confusion, the states of the switches in the (S1, S2, S3, S4) order are (0,0,0,0) for QPDX and (0,1,0,1) for QPDY.
  2. The Acromag XT1111 is a sinking BIO unit - so when the EPICS channel is zero, the output impedance is low and the DUT (i.e. MAX333) is shorted to ground. So, the state of the MAX333 shown on the schematics corresponds to EPICS logic level 1, and the switched state corresponds to logic level 0.
  3. For the laser pointer test, we used a red laser pointer. Using a power meter, we measured ~100uW of 632nm power. However, we think this particular laser pointer had failing batteries or something because the spot looked sometimes brighter/dimmer to the eye. Anyways, we saw ~10,000 ADC counts when illuminating a single segment (with the QPD gain switches at the 0,0,0,0 setting, before we changed anything). We expect 100uW * 0.4 A/W * 500 V/A * 10 * 40 * 4.5 * 3267.8 cts/V = ~12000 cts. So everything seems to check out. We changed the gain to the 5kohm setting and bypassed the subsequent gain stages, and saw the expected response too. The segments were only balanced to ~10%, but presumably this can be adjusted by tweaking digital gains.
  15040   Wed Nov 20 17:52:00 2019 gautamUpdateLSCQPD MEDM screen update

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.

Attachment 1: newLookQPD.png
newLookQPD.png
Attachment 2: TRX_TRY_comparison.pdf
TRX_TRY_comparison.pdf
Attachment 3: IMG_8186.JPG
IMG_8186.JPG
  3244   Mon Jul 19 14:14:03 2010 nancy, kojiUpdateIOOQPD Response Transfer Function

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)

 

  3245   Mon Jul 19 14:16:01 2010 nancy, kojiUpdateIOOQPD Response Transfer Function

Quote:

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 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.

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 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)

 

 QPDTF2.png

  8403   Wed Apr 3 16:03:59 2013 ChloeUpdate QPD Voltage Regulators

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.

  8406   Wed Apr 3 18:27:03 2013 KojiUpdate QPD Voltage Regulators

Breadboards may not be suitable for a reliable work. Why don't you switch to any protoboard and real soldering?

  626   Wed Jul 2 18:30:01 2008 JohnUpdateIOOQPD alignment
I aligned the beams on the following QPDs

IP POS
IP ANG
MC TRANS
IOO POS
Attachment 1: IOO080702.png
IOO080702.png
Attachment 2: MC080702.png
MC080702.png
  14219   Sun Sep 30 20:14:51 2018 yukiConfigurationASCQPD calibration

[ Yuki, Gautam, Steve ]

Results:
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

Details:
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:

  • Center beam spot on QPD using steering mirror, which was confirmed by monitored Pitch and Yaw signals that were around zero.  
  • Kept Y-axis micrometer fixed, moved X-axis micrometer and measured the outputs. 
  • Repeated the procedure for the Y-axis. 

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. 

Comments:

  • Some X-Y coupling existed. When one axis micrometer was moved, a little signal of the other direction was also generated.
  • As Gautam proposed in the previous study, there is some hysteresis. That process would bring some errors to this result.
  • A scale of micrometer is expressed in INCH!
  • The micrometer I used was made to have 1/2 inch range, but it didn't work well and the range of X-axis was much narrower. 

Reference:
previous experiment by Gautam for X-arm: elog:40m/8873, elog:40m/8884

Attachment 1: QPDcalibrationXaxis.pdf
QPDcalibrationXaxis.pdf
Attachment 2: QPDcalibrationYaxis.pdf
QPDcalibrationYaxis.pdf
  14221   Mon Oct 1 13:33:55 2018 yukiConfigurationASCQPD calibration
Quote:

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.

  • The SUM output was from -174 to -127 mV.
  • The beam radii calculated from the error func fittings was 0.47 mm.
  • Total optical path length measured by a ruler= 36 cm.
  • Beam power measured at QPD was 2.96 mW. (There are some loss mechanism in the setup.)

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].

Attachment 1: Pic_QPDcalibration.jpg
Pic_QPDcalibration.jpg
  8139   Fri Feb 22 17:33:38 2013 ChloeUpdate QPD circuit diagram

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. 

Attachment 1: IMG_0377.JPG
IMG_0377.JPG
  8090   Fri Feb 15 17:11:13 2013 ChloeUpdate QPD circuit pictures

 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. 

Attachment 1: IMG_0337.JPG
IMG_0337.JPG
Attachment 2: IMG_0338.JPG
IMG_0338.JPG
  8067   Tue Feb 12 17:26:31 2013 ChloeUpdate QPD circuitry to test mount vibrations

 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. 

  10174   Thu Jul 10 02:15:36 2014 JenneUpdateLSCQPD dark noise checkout

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. 

  10187   Fri Jul 11 20:05:34 2014 JenneUpdateLSCQPD dark noise checkout

The other day, I took spectra of the Yend transmission QPD dark noise for several different configurations of the transimpedance gain and the whitening gains. 

I also calculated with Optickle the expected sensitivity vs. CARM offset for the sqrtInv CARM sensor. 

I put these things together to get a plot of transmission QPD noise vs. CARM offset, for a chosen set of analog settings.


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.

TransQPDY_darkNoise_vs_TransimpedanceGain_9July2014.pdf

I then looked at the noise with different whitening gain slider settings.  All but one of the traces are the 20 kOhm setting.  

TransQPDY_darkNoise_vs_WhiteningGain_9July2014.pdf

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.

sqrtTrans_sensitivity.png


 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. 

sqrtTrans_Noise_vs_CARMoffset.png

  8618   Wed May 22 17:29:34 2013 JenneUpdateASCQPD for POP ASC tested

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.

  11056   Fri Feb 20 19:09:48 2015 ericqUpdateASCQPD frontend code unified

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:

  • The filter ini files
  • various MEDM screens
  • The optic misaligning scripts (which currently live in medm/MISC/ifoalign, and need to get moved to scripts/)
  • A recent BURT snapshot, to restore all of the switches and settings easily. 
  • scripts/activateDQ.py, which is responsible for renaming OL_PIT_IN1_DQ to OPLEV_PERROR, etc.

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. 

  11057   Mon Feb 23 08:06:59 2015 ranaUpdateASCQPD frontend code unified

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.

  3253   Tue Jul 20 18:29:43 2010 nancyUpdateIOOQPD installed behind the MC2

 

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.

  10786   Thu Dec 11 22:44:23 2014 ranaUpdateLSCQPD screens

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.

  42   Wed Oct 31 23:55:17 2007 waldmanOtherOMCQPD tests
The 4 QPDs for the OMC have been installed in the 056 at the test setup. All 4 QPDs work and have medm screens located under C2TPT. The breadboard mounted QPDs are not very well centered so their signal is somewhat crappy. But all 4 QPDs definitely see plenty of light. I include light and dark spectra below. QPDs 1-2 are table-mounted and QPD 2 is labeled with a bit of blue tape. QDPs 3-4 are mounted on the OMC. QPD3 is the near field detector and QPD4 is the far field. In other words, QPD3 is closest to the input coupler and QPD4 is farthest.

Included below are some spectra of the QPDs with and without light. For QPDs 1 & 2, the light source is just room lights, while 3&4 have the laser in the nominal OMC configuration with a few mWs as source. The noise at 100 Hz is about 100 microvolts / rtHz. If I recall correctly, the QPDs have 5 kOhm transimpedance (right Rich?) so this is 20 nanoamps / rtHz of current noise at the QPD.
Attachment 1: QPD_SignalSpectrum.pdf
QPD_SignalSpectrum.pdf
Attachment 2: QPD_SignalSpectrum.gif
QPD_SignalSpectrum.gif
  8358   Tue Mar 26 17:32:30 2013 ChloeUpdate QPD/ECDL Progress

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

Attachment 1: IMG-20130326-00245.jpg
IMG-20130326-00245.jpg
  1928   Wed Aug 19 17:11:33 2009 JenneUpdateIOOQPDs aligned

Quote:

 

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.

  10206   Tue Jul 15 21:43:28 2014 JenneUpdateLSCQPDs back

I removed the dumps in front of the trans QPDs.  The Yend QPD needed re-normalization, so I did that.

  12217   Mon Jun 27 15:47:17 2016 SteveUpdateGeneralQPR clean room gloves

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.

 

  10993   Tue Feb 10 02:55:29 2015 JenneConfigurationModern ControlQuacky filters

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:

  • Blue trace is the Wiener filter that I want, after the vectfit process.
  • Green trace is the frequency response of the SOS filters that are created by autoquack (really, quack_to_rule_them_all, which is called by autoquack).  The only thing that happens in matlab after this is formatting the coefficients into a string for writing to foton.
  • Red trace is the exported text file from foton.

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)

  3949   Thu Nov 18 16:42:29 2010 Joonho LeeConfigurationElectronicsQuad Video for PMCT, RCT, RCR fixed.

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.

  2510   Tue Jan 12 13:24:50 2010 HaixingUpdateSUSQuadrant Magnetic Levitation

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.

 

 

schmematic.png

 

(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.

  16348   Mon Sep 20 15:42:44 2021 Ian MacMillanSummaryComputersQuantization Code Summary

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. 

Signal Generation:

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.

State-space Model:

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

  \dot{x}(t)=\textbf{A}x(t)+ \textbf{B}u(t)   and  y(t)=\textbf{C}x(t)+ \textbf{D}u(t) ,

the model has three parts the first equation, an integration, and the second equation.

  1. The first equation takes the input x and the excitation u and generates the x dot vector shown on the left-hand side of the first state-space equation.
  2. The second part must integrate x to obtain the x that is found in the next equation. This uses the velocity and acceleration to integrate to the next x that will be plugged into the second equation
  3. The second equation in the state space representation takes the x vector we just calculated and then multiplies it with the sensing matrix C. we don't have a D matrix so this gives us the next output in our system

This system is the coded form of the block diagram of the state space representation shown in attachment 1

Direct-II Model:

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

y[n]=b_0 \omega [n]+b_1 \omega [n-1] +b_2 \omega [n-2],  where w[n] is  \omega[n]=x[n] - a_1 \omega [n-1] -a_2 \omega[n-2]

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.

Bode Plot: 

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 

G(f) = \frac{P_{csd}(f)}{P_{psd}(f)}

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

 

Attachment 1: 472px-Typical_State_Space_model.svg.png
472px-Typical_State_Space_model.svg.png
Attachment 2: Biquad_filter_DF-IIx.svg.png
Biquad_filter_DF-IIx.svg.png
Attachment 3: SS-IIR-TF.pdf
SS-IIR-TF.pdf
  16355   Wed Sep 22 14:22:35 2021 Ian MacMillanSummaryComputersQuantization Noise Calculation Summary

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):

  1. Feed different white noise data into three of the same filter this should yield the following equation: \textbf{S}_i^2 =\textbf{S}_{ni}^2+\textbf{S}_x^2, where \textbf{S}_i^2 is the power spectrum of the output for the ith filter,  \textbf{S}_{ni}^2 is the noise filtered through an "ideal" filter with no quantization noise, and  \textbf{S}_x^2 is the power spectrum of the quantization noise. Since we are feeding random noise into the input the power of the quantization noise should be the same for all three of our runs.
  2. Next, we have our three outputs:  \textbf{S}_1^2,  \textbf{S}_2^2, and  \textbf{S}_3^2 that follow the equations: 

\textbf{S}_1^2 =\textbf{S}_{n1}^2+\textbf{S}_x^2

\textbf{S}_2^2 =\textbf{S}_{n2}^2+\textbf{S}_x^2

\textbf{S}_3^2 =\textbf{S}_{n3}^2+\textbf{S}_x^2

From these three equations, we calculate the three quantities: \textbf{S}_{12}^2\textbf{S}_{23}^2, and \textbf{S}_{13}^2 which are calculated by:

\textbf{S}_{12}^2 =\textbf{S}_{1}^2-\textbf{S}_2^2\approx \textbf{S}_{n1}^2 -\textbf{S}_{n2}^2

\textbf{S}_{23}^2 =\textbf{S}_{2}^2-\textbf{S}_3^2\approx \textbf{S}_{n2}^2 -\textbf{S}_{n3}^2

\textbf{S}_{13}^2 =\textbf{S}_{1}^2-\textbf{S}_3^2\approx \textbf{S}_{n1}^2 -\textbf{S}_{n3}^2

from these quantities, we can calculate three values: \bar{\textbf{S}}_{n1}^2\bar{\textbf{S}}_{n2}^2, and \bar{\textbf{S}}_{n3}^2 since these are just estimates we are using a bar on top. These are calculated using:

\bar{\textbf{S}}_{n1}^2\approx\frac{1}{2}(\textbf{S}_{12}^2+\textbf{S}_{13}^2+\textbf{S}_{23}^2)

\bar{\textbf{S}}_{n2}^2\approx\frac{1}{2}(-\textbf{S}_{12}^2+\textbf{S}_{13}^2+\textbf{S}_{23}^2)

\bar{\textbf{S}}_{n3}^2\approx\frac{1}{2}(\textbf{S}_{12}^2+\textbf{S}_{13}^2-\textbf{S}_{23}^2)

using these estimates we can then estimate  \textbf{S}_{x}^2  using the formula:

\textbf{S}_{x}^2 \approx \textbf{S}_{1}^2 - \bar{\textbf{S}}_{n1}^2 \approx \textbf{S}_{2}^2 - \bar{\textbf{S}}_{2}^2 \approx \textbf{S}_{3}^2 - \bar{\textbf{S}}_{n3}^2

we can average the three estimates for  \textbf{S}_{x}^2  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. 

Next steps:

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. 

Attachment 1: IIR64-bitnoisespectrum.pdf
IIR64-bitnoisespectrum.pdf
  16360   Mon Sep 27 12:12:15 2021 Ian MacMillanSummaryComputersQuantization Noise Calculation Summary

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)

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 f(t) then it is filtered and the result is the filtered data x(t) thus we get the result: f(t)\rightarrow x(t)=x_N(t)+x_q(t)  where x_N(t) is the raw noise filtered through an ideal filter and x_q(t) 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 e(t):
e(t)=x_{32}(t)-x_{64}(t)=x_{N_{32}}(t)+x_{q_{32}}(t) - x_{N_{64}}(t)-x_{q_{64}}(t)
and since x_{N_{32}}(t)=x_{N_{64}}(t) because they are both running through ideal filters:
e(t)=x_{N}(t)+x_{q_{32}}(t) - x_{N}(t)-x_{q_{64}}(t)
e(t)=x_{q_{32}}(t) -x_{q_{64}}(t)
and since in this case, we are assuming that the higher bit-rate process is essentially noiseless we get the Quantization noise x_{q_{32}}(t).

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)

From this assumption, we can say that the noise difference between the 32-bit and 64-bit filter outputs:  x_{q_{32}}(t)-x_{q_{64}}(t)  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

  16361   Mon Sep 27 16:03:15 2021 Ian MacMillanSummaryComputersQuantization Noise Calculation Summary

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.

Attachment 1: DeltaNoiseSpectrum.pdf
DeltaNoiseSpectrum.pdf
  16362   Mon Sep 27 17:04:43 2021 ranaSummaryComputersQuantization Noise Calculation Summary

I suggest that you

  1. change the corner frequency to 10 Hz as I suggested last week. This filter, as it is, is going to give you trouble.
  2. Put in a sine wave at 3.4283 Hz with an amplitude of 1, rather than white noise. In this way, its not necessary to do any subtraction. Just make PSD of the output of each filter.
  3. Be careful about window length and window function. If you don't do this carefully, your PSD will be polluted by window bleeding.

 

  16366   Thu Sep 30 11:46:33 2021 Ian MacMillanSummaryComputersQuantization Noise Calculation Summary

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

Attachment 1: SS-IIR-Bode.pdf
SS-IIR-Bode.pdf
Attachment 2: PSD_32bit.pdf
PSD_32bit.pdf
Attachment 3: PSD_64bit.pdf
PSD_64bit.pdf
  16481   Wed Nov 24 11:02:23 2021 Ian MacMillanSummaryComputersQuantization Noise Calculation Summary

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. 

Notebook Summary:

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.

  0.1 Amplitude of input 1 Amplitude 100 Amplitude 1000 Amplitude
4-bit SNR 5.06e5 5.07e5 5.07e5 5.07e5
8-bit SNR 5.08e5 5.08e5 5.08e5 5.08e5
16-bit SNR 2.57e6 8.39e6 3.94e6 1.27e6
32-bit SNR 7.20e17 6.31e17 1.311e18 1.86e18
64-bit SNR 6.0e32 1.28e32 1.06e32 2.42e32
128-bit SNR unknown unknown unknown unknown

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.

 

Attachment 1: PSD_IIR_all.pdf
PSD_IIR_all.pdf
  16482   Wed Nov 24 13:44:19 2021 ranaSummaryComputersQuantization Noise Calculation Summary

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.

  16492   Tue Dec 7 10:55:25 2021 Ian MacMillanSummaryComputersQuantization Noise Calculation Summary

[Ian, Tega]

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.

State Space:

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

 

 

Attachment 1: DF2_TS.pdf
DF2_TS.pdf
Attachment 2: BIQ_TS.pdf
BIQ_TS.pdf
Attachment 4: PSD_COMP_BIQ_DF2.pdf
PSD_COMP_BIQ_DF2.pdf
Attachment 5: PSD_COMP_SS_DF2.pdf
PSD_COMP_SS_DF2.pdf
ELOG V3.1.3-