While attempting to develop a somewhat accurate noise budget for the 40m, I reasoned that while the shape of the transfer function for the ISS is important, the degree to which we can 'tune' it to a particular experiment/application is limited.

• Since we're using a DC-coupled servo, the TF magnitude will go like f^k with k < 0 for low frequency.
• The UGF will be somewhere around 10 kHz to 1 MHz (most likely right around 100 kHz) as beyond 1 MHz, the gain of our servo is limited by the GBWP of the op-amps.
• We need around 3 or 4 orders of magnitude of gain in the 1-100 Hz range based on this, with gain > 10 for f < 10 kHz

Beyond that, we're sort of limited by the desired high and low frequency behavior as well as the general principle that more electronics = more noise so we probably don't want more than 3 or 4 filter stages, if that. Additionally, the ISS can be over-engineered so that it suppresses the laser noise to levels well below other fundamental noise sources over the important regime ~10 - 10^3 Hz without particular regard to a noise budget.

The design I propose is very similar to a previous design, with a few adjustments. It consists of 3 filter stages that easily be modified to increase gain for higher frequencies if it is known/determined that the laser being stabilized has a lot of high frequency noise.

Stage 1: Basic LP Filter + Establish UGF (each stage 'turning on' will not change the UGF),  Stage 2: Integrator with zero @ 10 kHz,  Stage 3: Optional extra gain if necessary

With the full TF given by,

As usual we consider the noise caused by the servo itself. Noise analysis in LISO is done with a 1 V input excitation.

This servo should function sufficiently for the 40m.

 After familiarizing myself with Altium, I drew up the attached schematic for the ISS to be used in the CTN experiment. The filename includes 'abbott-switch' as I am using an Altium component (the switch, in particular), that he created. The MAX333A actually has 20 pins on a single component, but the distributed component that he created is useful for drawing uncluttered schematics. I won't be using all of the pins on this switch, but for completeness, I have included the 3rd and 4th portion of the full component in the upper right hand corner.

Currently, the schematic includes the voltage reference (AD586), a LP filter for the reference signal, the differential amplifier stage to obtain the error signal and then finally all of the filter stages. The schematic does not include the RMS detection and subsequent triggering of each filter stage. The TRIGGER 1 signal is a user input (essentially the on button) while the TRIGGER 2 signal will flip the second switch when the RMS noise has decreased sufficiently after the first filter stage has been turned on. 

PCB layouts will be done once I understand that part of Altium 

NOTE THAT I HAVE DELETED ELOG 8798 AS IT WAS A DUPLICATE OF THIS ONE.

I wanted this elog to be in reply to a previous one and I couldn't figure out how to change that in an elog I already submitted.

There are essentially two major portions of the ISS I am designing. One system has the voltage reference, differential amplifier and filtering servo (schematic attached) while the other has a comparator circuit and a triggering mechanism. The first system amplifies an error signal obtained from the PD output and the voltage reference, which is then fed back through the AOM. I've done a lot of work designing/prototyping this first half and now I'm starting to design the second half.

The second system's main purpose is to maintain loop stability as the ISS is engaged. Let's assume a user has decided they want noise suppression. They would first close the ISS feedback loop and an error signal would pass through three unity-gain buffers, providing minimal noise reduction. The user can then send a signal to theTRIGGER 1 port to switch the first stage from its unity-gain position to its filtering position and reduce the intensity noise further. This signal will most likely be digital in origin. Alternatively, when the user first closes the ISS loop, the first stage can already be in its filtering position rather than necessitating two commands.

A test channel (not drawn in the included schematic) will monitor the RMS level of the incoming signal from the PD. This noisy AC signal will first be amplified and then passed through an RMS-to-DC converter. The resulting DC signal is used as a part of the triggering mechanism for later stages. Once the first stage has been switched manually, and the DC signal corresponding to RMS noise of the PD output drops below a certain threshold, stages 2 and 3 will be internally triggered with a short delay between them. Toward being able to detect this threshold, I have designed a simple comparator circuit with an LT1016. The circuit has a fairly low-level output when the input voltage is larger than the threshold (about 1.6 V for my simple prototype), but when the input passes below the threshold, the comparator puts out almost 4 V, a number limited by the supply voltage. The schematic is shown below.

The component V2 and the various voltage dividers serve to establish the reference/threshold voltage. Note that although the LT1016 is not powered in the schematic, it requires ±5 V (a max of 7 V). The above circuit was also prototyped on a breadboard and I characterized it with an oscilloscope. Using a CFG253, I made a low frequency (~0.3 Hz) triangle wave with an amplitude and DC offset such that it oscillates between 0 and 5 V. This was applied to the IN node in the above schematic. The input waveform and the circuit's response (voltage at the OUT node) are shown below. As expected, R2 serves to establish hysteresis. The comparator switches to 'high' output until the input drops below 1.6 V, and then it doesn't switch back to the 'low' output until the input goes up to ~3.4 V.

This behavior is ideal for our application as we can detect when the DC signal from the RMS-to-DC converter drops below a certain level (i.e. the first stage that has been activated does some amount of filtering to lower RMS noise), and then we can trigger subsequent filter stages off of the comparators high-level output. 

This circuit could easily be used to drive the MAX333a switches shown in the first schematic attached. I believe the low-level output is not sufficient to switch the MAX333a although the ~4 V high-level output is quite sufficient. Regardless, these exact values (thresholds, outputs etc) will be determined after I have a better idea of the RMS noise of the laser without any intensity stabilization as well as a solid understanding of how the AD8436 RMS-to-DC converter works. This was simply a proof of concept for lower threshold detection using basic Schmitt trigger topology.

I went out on the floor to look at the transmitted signal from the PMC to get a rough idea of the noise of the unstabilized laser. There was already a scope hooked up so I just used the measurement features to find the following:

Signal average = 875 mV.  Peak-to-Peak noise = 45 mV

Assuming the noise can be approximated as Gaussian noise, the heuristic for converting to RMS noise of the signal is RMS = Peak-to-Peak / 8 (or Peak-to-Peak / 6, I've used both...)

-> RMS Noise ~ 6.5 mV

When designing my filtering stages and RMS detection/triggering, I'll use relative RMS, i.e. 6 mV / 875 mV = 0.007, as a measure of unstabilized laser noise.

I wanted the RMS noise simply to establish a very rough estimate of thresholds on RMS detectors that will be part of my device. If you refer to elog 8830, I explain it there. Essentially, when the ISS is first engaged, only one of the 2 or 3 filter stages will be active. Internal RMS threshold detection serves to create a logic input to switch subsequent filters to their 'on' stage.

 Here I have included the full schematic (so far) of the proposed ISS. There are two sheets: the first schematic details the filter stages and their accompanying circuitry while the second schematic details the RMS threshold detection and subsequent triggering.

The first schematic is fairly self explanatory as to what different portions do, and I have annotated much of the second schematic as there are some non-traditional components etc.

I have not yet included some mechanism to adjust the threshold voltage in real time or any of the power regulation, but these should follow fairly quickly.

 I have made significant changes to the ISS schematic, mostly in the form of adding necessary subsystems.

Some changes I have made:

• Added a front page with sheet symbols that are representations of the other schematic sheets.
• Added an 'Excitation' subsystem for use in determining the closed-loop transfer function
• Added an instrumentation amplifier (with ADA4004s at Rana's recent suggestion) to handle the differential input from the PD
• Included a switchable inverting amplifier (Gain of 1 or -1) to ensure we have the correct polarity
• Made it so the first filtering stage is immediately active when the ISS loop is closed
• Added LP filters with large time constants to buffer/delay trigger signals
• Added test points all over the board
• Refined a few buffer amplifiers

On the front page, all inputs and outputs are currently BNC ports, although this is most likely not the final design that will be used. For instance, the ports ENABLE, INPUT GND and INVERT are supposed to be logic inputs for a MAX333a switch. These will most likely be front panel switches that either connect the switch's logic pin to GND (Logic 0) or something like a +5 V supply (Logic 1).

I also have not included power regulation for my board although I have some of the actual D1000217 Chasis Power Regulator boards and I'll incorporate those in my design soon.

 I realized I totally forgot to post this last week, but I prototyped the comparator and boost triggering portion of the ISS, at least in part. Below is a schematic that shows the prototype circuit I made. Note that it includes ports for the oscilloscope channels that appear in the second image included. Essentially, I was able to verify that the output from the LT1016, as it's currently constructed in the ISS schematic, would be sufficient logic to switch the MAX333a.

Below, we can first see that the comparator is switching its output as desired. When the DC level of the input drops below a certain threshold (~1.6 V) the output of the comparator switches on to ~4 V. When the DC level of the input goes back up above the upper threshold (~3.2 V), the comparator switches off to ~0.3 V. The exact values of the threshold voltages can be determined/tuned at a later date, but this is the basic behavior that the comparator circuit will have.

To detect whether or not the MAX333a was switching properly, I connected the common terminal of one of the switches to a +5 V supply, and looked at the voltage coming off both the 'open' and 'closed' terminals of said SPDT switch. We can see that with Logic 0 (comparator output ~0.3 V) Channel 4 exhibits a ~5 V signal, just as we would expect from the above schematic. With Logic 1 (comparator output ~4 V), Channel 3 exhibits the characteristic 5 V signal.

I constructed a regulator board that can take ±24 V and supply a regulated ±15 V or ±5 V. I followed the schematics from LIGO-D1000217-v1.

I was going to make 2 boards, one for ±15 V and one for ±5, but Chub just gave me a second assembled board when I asked him for the parts to construct it 

 More changes that I've made:

• Added daughter boards for power regulation. Currently I have ±24V going into two boards, with ±15V coming out of one and ±5V coming out of the other. Again, these are based off of LIGO-D1000217
• Added an optional Dewhitening filter (with p=1Hz and z=100Hz, although these can easily be changed) to accommodate any PD's that have whitening
• Added a bypass to allow the boosts (stages 2 and 3 of the filtering servo) to be enabled/disabled by a front panel switch
• I also put in jumpers that can be used to provide Logic 1 (boost enabled) to both Boost 1 and Boost 2 without depending on the internal RMS detection/triggering
• Changed the input grounding switch so that it's set up correctly. Before, it was taking the PD signal and sending it to GND, not actually grounding the input to the rest of the ISS 

 In PSL elog 1270, Evan elucidated the explicit requirements for the CTN ISS board. Essentially, the transfer function of the ISS should be something like:

     TF_mag = (Unstabilized RIN) / (Calculated RIN Requirement)

I took Evan's data and did exactly this. I then designed a servo (using the general design I proposed here) to meet this requirement with a safety factor of ~10. By safety factor, I mean that if the ISS operates exactly according to theory, it should suppress the noise by a factor of 10 more than what is necessary/set out by the requirement. Below is a plot of the loop gain obtained directly from the requirement (the above expression for TF_mag) and the transfer function of the servo I am proposing.

I don't have the actual schematics attached as I was working with a LISO file and have yet to update the corresponding Altium schematic. The LISO file is attached and I will add the schematics later, although one can reference the second link to find a simple drawing.

Attached is the finalized schematic. The general circuit topology should remain the same from this point forward, although individual component values are subject to change. I will also be adding some more annotations to ensure everything on the board is clear.

In general, I have finally included all of the correct components (i.e. front panel switches are now actually switches and front panel LEDs are now included). I also added an external 'Boost' switch, which can be used to enable or disable the boosts. The motivation for including this switch is that one might want to test functionality of the ISS without using the 'fancy' RMS detection and triggering circuitry. Additionally, one can disable the boosts when all the circuitry is stuffed in order to troubleshoot, so it essentially grants the board some flexibility in its operation.

I am now working on the PCB layout and I should hopefully have that done next week. 

 After many, many moons of getting to know exactly how frustrating Altium can be, I have completed the PCB layout for my ISS board (final page of ISS_v3.pdf).

Before I get into detail about the PCB, there is one significant schematic change to note: the comparator circuit was changed (with significant help from Koji) so that the voltage reference for boost triggering is established in a more logical way. Instead of the somewhat convoluted topology I had before, now there are only two feedback resistors, R82 and R83. Because their resistances (500k and 50k respectively) are so much larger than the total resistance of the 1k potentiometer (used to establish a tunable threshold voltage), the current flowing through the feedback loop is negligible compared to the 5 mA current flowing through the potentiometer (the pot is rated for 2 W and with 5 mA -> 25 mW dissapation). This allows one to set the threshold voltage for my schmitt trigger, at pin 2 of both the pot and the comparator, entirely with the pot. This trigger also has hysteresis given by the relation deltaV ~ (R83/R82) * (Voh - Vol) where deltaV is the separation between threshold voltages, Voh is the high-level comparator ouput and Vol is the low-level comparator output. Koji simulated this using CircuitLab and I plan to verify the behavior by making a quick prototype circuit.

Now, on to the PCB. The board itself is of a 'standard' LIGO size (11" x 6") has 3 routing layers and 3 internal planes, one for +15 V, one for -15 V and one for GND. In the attached pdf, red is the top routing layer, blue is the bottom layer and brown is the middle routing layer (used for ±5 V exclusively). The grey circles are pads and vias (drilled through) and anything in black is silkscreen overlay. I placed each component and track by hand, attempting to minimize the signal path and following the general rules below,

• Headers for power, ±5 V and ±15V, are at the back of the board
• For sections of the board such as filter stages or buffers, resistors and capacitors were grouped around their respective op-amps.
• As often as was possible, routing was confined to the top layer. Tracks on the bottom layer were placed mostly out of necessity (i.e. no possible connection on top routing layer).
• The signal generally proceeds from left to right (directions with respect to the attached printout) in the same logical order as on the schematic sheets. Refer to the global sheet (page 1) of the attached "ISS_v3.pdf".
• External ports such as the PD input, various monitoring ports and panel mounted switches/LEDs were all connected to the board via headers located along the front edge. These are also ordered following the schematic layout.
• Occasionally, similar signal paths were grouped together although this was a rarity on my board

Sections of the board have been partitioned and labeled with silkscreen overlay to help in both signal pathway recognition as well as eventual troubleshooting.

On the board, I have also included holes so that it can be mounted inside of an enclosure. There is a DCC number printed as well as a 'barcode' (TrueType font: IDAutomationC39S), although they both contain filler asterisks as I haven't published this to the DCC and thus do not have a number.

Rana and I connected the PMC_trans output to the BNC connector board on the west end of the PSL table (the channel is labeled). I took a few spectra off of PMC_trans and the SR785 was connected directly to the PMC_trans output for about an hour.

Data will follow.

 I was working on the electronics bench and what sounded like a huge truck rolled by outside. I didn't notice anything until now, but It looks like something became misaligned when the truck passed by (~6:45-6:50 pm). I can hear a lot of noise coming out of the control room speakers and pretty much all of the IOO plots on the wall have sharp discontinuities.

I haven't been moving around much for the past 2 hours so I don't think it was me, but I thought it was worth noting.

 Previously in elog 8959, I gave a very simple method for determining the noise suppression behavior of the ISS. Recently, I recalculated this requirement in a more correct fashion and again redesigned the ISS to be used in the CTN experiment.

• Determining the Requirement

Just as before, the data from PSL elog 1270 is necessary to infer a noise suppression requirement. The data presented there by Evan consists of two noise spectra, 1) the unstabilized RIN presently observed in the CTN experiment readout and 2) the theoretical brownian noise produced by thermal processes in the mirror coating+substrate. The statement "TF_mag = (Unstabilized RIN) / (Calculated Brownian Noise Limit)", where TF_mag refers to the required open-loop gain of the ISS, is actually a first order approximation of the 'required' noise suppression. In fact if we wanted the laser noise to be suppressed below the calculated brownian noise level, it is more correct to say 

        Closed-loop ISS gain = (Calculated Brownian Noise Limit) / (Unstabilized RIN)

As this essentially gives a noise suppression spectrum i.e. a closed-loop gain in linear control theory. Below is a very simple block diagram showing how the ISS fits into the CTN experiment. The F(f) block represents my full servo board.

Some of the relevant quantities involved:

So looking at the block diagram, our full closed-loop transfer function is given by,

So then to determine the required F(f), i.e. the required transfer function for my servo, we consider the expression 

The plant transfer function is simply Plant = (C(f) * a * P * A) ~ 0.014 V/V, where I have ignored the cavity pole around 97 kHz as our open-loop transfer function ends up crossing unity gain around 10 kHz. In the above, I have included what I call a 'safety factor' of 10. Essentially, I want to design my servo such that it suppresses noise well beyond what is actually required so that we can be sure noise contributions to experiment readouts are not significantly influenced by the laser intensity noise.

• Proposed Servo Design

Using the data Evan reported for the brownian noise and free-running RIN, I came up with an F(f) to the meet the requirement as shown below.

 Where the blue curve includes the safety factor mentioned before. This plot just demonstrates that using my modular ISS design, I can meet the given noise suppression requirements.

To be complete, I'll say a little more about the final design.  As usual, the servo consists of three stages. The first is the usual LP filter that is always 'on' when the ISS loop is closed. The boosts I have chosen to use consist of an integrator with a single zero and a filter that looks somewhat like a de-whitening filter. The simulated open-loop transfer functions are shown below.

Right near the end of summer, I had an ISS board that was nominally working, but had a few problems I couldn't really sort out. Since I've been back, I've spent a lot of time just replacing parts, trying different circuit topologies and generally attempting to make the board function as I hoped it might in all those design stages. Below is a brief list of some of the problems I've been fixing as well as the first good characterization of the board transfer function that I've been able to get.

We'll start with some of the simple problems and proceed to more complicated ones.

• The 5V reference I was using to obtain an error signal from some arbitrary DC photodiode readout was only producing ~2.5 V. 
  • Turns out I just need a FET type op-amp for the Sallen-Key Filter that I was using to clean up any noise in the reference output, as the leakage current in a AD829 was causing a significant voltage drop. I put in an OPA140 and everything worked marvelously.
• The way I set up input grounding (i.e. send a ~0 amplitude signal through the board as an input) passed a few Amps through one of my chips causing it to burn out rather fantastically.
  • There isn't a good way to fix this on the current board (besides just getting rid of the functionality altogether) so my solution so far has just been to redesign that particular sub-system/feature and when we implement the second version of the ISS, the input grounding will be done correctly
• One of the ICs I'm using, specifically the AD8436 RMS-to-DC converter, causes some super strange oscillations in -5V power line. When this chip is soldered onto the board, the -5V supply jumps between -3V and -10V rather sporadically and the DC power-supply used to provide that -5V says that board is drawing ~600 mA on that particular power line.
  • To date, I don't really have any idea what's going with this chip, and I've tried a lot of things to remedy the problem. My first thought was that I had some sort of short somewhere so I took the chip off the board, cleaned up all the excess solder and flux around the chip's footprint and then meticulously soldered a new chip on (when I say meticulously, it took over an hour to solder 20 little feet. I really really didn't want to short anything accidentally as the chip only comes in a package with ridicously small spacing between the leads). Lo and behold, nothing happened. I still saw the same oscillations in power supply and the board was still drawing between >500 mA on that line. Just to be sure, I soldered on a third chip taking the same amount of care and had the same problems.
  • I went over the schematic in Altium that we used to order the board, and unless the manufacturer made a mistake somewhere, there aren't any incorrectly routed signals would cause, say, two active devices to try setting the voltage of a particular node to different values.
  • I got some QSOP-to-DIP package converters so that I could mess around with the AD8436 on a breadboard to make sure it functioned correctly. I set up an identical circuit to the one on the PCB and didn't see any oscillations in the power supply, both for +-5V and +-15V as the chip can handle both supply voltages. I'm not really sure how to interpret this...
  • I'm still actively trying to figure this particular problem out, but I'm shooting in the dark at this point. 
• Initial attempts to measure the transfer-function of the board were wrought with failure.
  • I figured out, with Nic's help, that the board needs the 'loop closed' with a significant broadband attenuator (to simulate the plant optics discussed in elog 9331) in order to not have constant railing of the high gain op-amp filter stages. Even after I did this, the measured transfer functions were not at all consistent with simulation. I wasn't sure if it was just a part issue, a design issue or a misunderstanding/bad data collection on my part so I just redesigned the whole servo and stuffed the board with entirely new components from around the 40m. Turns out the newly designed servo behaved more properly, as I will show below.

The above list encompasses all the issues I've had in making the ISS board function correctly. No other major problems exist to my knowledge.

I was able to measure both the open- and closed-loop transfer functions of the servo with the SR785. The results are shown below.

The transfer function with the boosts on caps at a particular value set by op-amp railing, i.e. below 100 Hz, the op-amps are already putting out their max voltage. This is the usual physical limitation when measuring the transfer function of an integrator. We can also see that the measured phase follows the simulated phase above ~300 Hz. The 'phase matching' at low frequency is again do to the op-amp railing in the servo output..

The closed-loop gain is shown below,

The measured closed-loop gain with the boosts on again matches the LISO simulation quite well except at low frequency where we are limited by op-amp railing. We compare the measured closed-loop transfer function to the desired noise suppression stipulated in my previous elog 9331,

 And we might hopefully conclude that my servo functions as desired. One should note that the op-amp railing seen in these measurements is not indicative of limitations we might face in some application of the ISS for the following reason. These transfer functions were measured with a 100 mV excitation signal (it is necessary to keep this signal amplitude large enough so that the inherent signal-to-noise ratio of the excitation source is large enough for accurate measurement) which leads to somewhat prompt railing of the op-amps. When the ISS operates to actually stabilize a laser, the input error signal will be much smaller (on the order of a few 10's of mV or less) and will decrease significantly assuming correct operation of the ISS. This means we won't see the same type of gain limitations.

What now, you ask?

Aside from the problem with the AD8436 chip, the ISS board seems to be functioning correctly. The transfer functions we have measured are correct to within the component tolerances and all of the various subsystems are behaving as they were designed to. Moving toward the goal of having this system work in situ for the CTN experiment, I need to do the following things,

• Design a housing for the board -> order said housing and the front panel previously designed
• Make sure the power supply daughter PCB boards are compatible with the ISS board and can provide power correctly
• Talk to Evan and Tara about integrating the ISS with their experiment and make sure my board can do everything it needs to in that context.

So close, or so I say all the time 

 The 40m experienced a building-wide power failure for ~30 seconds at ~7:38 pm today.

Thought that might be important...

The following is a message from the LIGO 40m Chief Recycling Officer:

Please get up off your (Alignment Stabilization Servo)es and recycle your bottles and cans!  There is a recycling bin in the control room.  Recent weeks have seen an increase in number of bottles/cans thrown away in the regular garbage.  This is not cool. 

Thank you,

---L4mCRO

I am going to be making measurements to find the optical mounts with the least noise. I am using a quadrature photodiode to record intensity of laser light. These are pictures of the circuitry inside (both sides). I will be designing/making some circuitry on a breadboard in the next few days in order to add and subtract the signals to have pitch and yaw outputs.

 I spent awhile today reading about op-amps and understanding what would be necessary to design a circuit which would directly give pitch and yaw of the QPD I am using. After getting an idea of what signals would be summed or subtracted, I opened up the QPD to take better pictures than last time (sorry, the pictures were blurry last time and I didn't realize). It turns out some of the connections have been broken inside the QPD, which would explain why we saw an unchanging signal in Ch2 on the oscilloscope yesterday when trying to test the laser setup. 

I found a couple other QPDs, which I will be using to help understand the circuit (and what is going on). I will be trying to use the same QPD box since it has banana cable and BNC cable adapters, which is helpful to have in the lab. Once I have concluded what the circuitry is like and designed electronics to add and subtract signals, I will build and mount all the circuits within the box (more sturdily than last time) so as to have a quality way of measuring the mount vibrations when I get there. 

 I took better pictures of the circuits of the QPD and spent a couple of hours with a multimeter trying to figure out how all the connections worked. I will continue to do so and analyze the circuits over the weekend to try to understand what is going on. I also have an old SURF report that Eric sent me that is similar to the design I was planning to use to sum the pitch and yaw signals. I will try and look at this over the weekend. 

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.

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

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

This is the final version of the QPD circuit I'm going to build. After playing around with the spatial arrangement, this should fit into the box that I was planning to use, although it will be a rather tight fit. The pitch, yaw, and summing circuit will be handled with a quad op amp. Planning to meet with Eric tomorrow to figure out the logistics of building things.

In the meantime, I'm reading about designing the ECDL for my summer project with Tara. He sent me several papers to read so we can talk on Wednesday.

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

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

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.

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.

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 found two ThorLabs PDA55 Si photodetectors that says detect visible light from DC to 10MHz that I'm going to use from now on.  I don't know how low of a frequency they will actually be good to.

David and I were thinking about changing the non-polarizing beam splitter in the EUCLID setup from 50/50 to 33/66 (ref picture).  It serves as a) a pickoff to sample the input power and b) a splitter to send the returning beam to a photodetector 2 (it then hits a polarizer and half of this is lost.  By changing the reflectivity to 66% then less (1/3 instead of 1/2) of the power coming into it would be "lost" at the ref photodetector 1, and on the return trip less would be lost at the polarizer (1/6 instead of 1/4).

For the past week Dmass and I have been ordering parts and getting ready to construct our own modified version of EUCLID (figure).  Changes to the EUCLID design could include the removal of the first lens, the replacement of the cat's eye retroreflector with a lens focusing the beam waist on a mirror in that arm of the Michelson, and the removal of the linear polarizers.  A beam dump was added above the first polarizing beam splitter and the beam at Photodetector 2 was attenuated with an additional polarizing beam splitter and beam dump.  Another proposed alteration is to change the non-polarizing beam splitter from 50/50 to 33/66.  By changing the reflectivity to 66\%, less power coming into the non-polarizing beam splitter would be ``lost" at the reference detector (1/3 instead of 1/2), and on the return trip less power would be lost at the polarizing beam splitter (1/6 instead of 1/4).  Also, here's a noise plot comparing a few displacement sensors that are used to the shot noise levels for the three designs I've been looking at.

 I thought slightly harder and I think that the beamsplitter stays. We will lose too much power on the first PD if we do that:

33/66:  Pwr @ PD2 = 2/3*1/3*1/2 =  1/9 Pin

            Pwr @ PD3 = 2/3*2/3*1/2 = 2/9 Pin

50:50 Pwr @ PD2 = PWR @ PD3 = 1/8 Pin

balancing them is probably better.

Today I set up the EUCLID long range michelson design on the SP table; It's the same as the setup posted earlier, but without the pickoff (at PD1), which can be added later, and a few other minor changes (moved lenses, mirrors, PDs - nothing major).  I hooked up the two PD's to the oscilliscope and got a readout that pointed to more power hitting PD2 than PD3.

The EUCLID-style Michelson readout is on the SP table now and is aligned.  See image below.  I took several power spectra with the plotter attached to the HP3563 (not sure if there's another way to get the data out) and I'm still waiting to calibrate (since dP/dL isn't constant as it isn't locked, this is taking a bit longer).  When put into XY mode on the oscilliscope (plotting Voltage at PD2 on the x and Voltage at PD3 on the y), a Lissajous figure as in the first plot below.  It's offset and elliptical due to imperfections (noise, dc offset, etc) but can ideally be used to calculate the L_ target mirror movement.  By rotating the first quarter wave plate by ~80.5deg counter-clockwise (fast axis was originally at Pi/8, now at 103deg), I was able to turn the Lissajous figure from an ellipse into a more circular shape, which would ideally allow for us to use a circular approximation (much simpler) in our displacement calculations.

 We fixed this problem (at least for now) by adding c1auxex to the /etc/hosts file on chiara (following a hint from this page). The DNS setup might be the culprit here.

Yesterday elog was excruciatingly slow, and bingbot was the culprit. It was slurping down elog entries and attachments so fast that it brought nodus to its knees. So I created a robots.txt file disallowing all bots, and placed it in the elog's scripts directory (which gets served at the top level). Today the log feels a little snappier -- there's now much less bot traffic to compete with when using it.

We might be able to let selected bots back in with a crawl rate limit, if anyone misses searching the elog on bing.

The recently observed daqd flakiness looks related to this transfer. It appears to still be ongoing:

nodus:~>ps -ef | grep rsync
controls 29089   382  5 13:39:20 pts/1   13:55 rsync -a --inplace --delete --exclude lost+found --exclude .*.gwf /frames/trend
controls 29100   382  2 13:39:43 pts/1    9:15 rsync -a --delete --exclude lost+found --exclude .*.gwf /frames/full/10975 131.
controls 29109   382  3 13:39:43 pts/1    9:10 rsync -a --delete --exclude lost+found --exclude .*.gwf /frames/full/10978 131.
controls 29103   382  3 13:39:43 pts/1    9:14 rsync -a --delete --exclude lost+found --exclude .*.gwf /frames/full/10976 131.
controls 29112   382  3 13:39:43 pts/1    9:18 rsync -a --delete --exclude lost+found --exclude .*.gwf /frames/full/10979 131.
controls 29099   382  2 13:39:43 pts/1    9:14 rsync -a --delete --exclude lost+found --exclude .*.gwf /frames/full/10974 131.
controls 29106   382  3 13:39:43 pts/1    9:13 rsync -a --delete --exclude lost+found --exclude .*.gwf /frames/full/10977 131.
controls 29620 29603  0 20:40:48 pts/3    0:00 grep rsync

Diagnosing the problem:

I logged into fb and ran "top". It said that fb was waiting for disk I/O ~60% of the time (according to the "%wa" number in the header). There were 8 nfsd (network file server) processes running with several of them listed in status "D" (waiting for disk). The daqd logs were ending with errors like the following suggesting that it couldn't keep up with the flow of data:

[Wed Oct 22 18:58:35 2014] main profiler warning: 1 empty blocks in the buffer
[Wed Oct 22 18:58:36 2014] main profiler warning: 0 empty blocks in the buffer
GPS time jumped from 1098064730 to 1098064731

This all pointed to the possibility that the file transfer load was too heavy.

Reducing the load:

The following configuration changes were applied on fb.

Edited /etc/conf.d/nfs to reduce the number of nfsd processes from 8 to 1:

OPTS_RPC_NFSD="1"

(was "8")

Ran "ionice" to raise the priority of the framebuilder process (daqd):

controls@fb /opt/rtcds/rtscore/trunk/src/daqd 0$ sudo ionice -c 1 -p 10964

And to reduce the priority of the nfsd process:

controls@fb /opt/rtcds/rtscore/trunk/src/daqd 0$ sudo ionice -c 2 -p 11198

I also tried punishing nfsd with an even lower priority ("-c 3"), but that was causing the workstations to lag noticeably.

After these changes the %wa value went from ~60% to ~20%, and daqd seems to die less often, but some further throttling may still be in order.

I think the dolphin and RFM transit times are double-counted in this budget. As I understand it, all IPC transit times are already built in to the cycle time of the sending model. That is, the sending model is required to finish its computational work a little bit early, so there's time left to transmit data to the receivers before the start of the next cycle. Otherwise you get IPC errors. (This is why the LSC models at the sites can't use the last ~20 usec of their cycle without triggering IPC errors. They have to allow that much time for the RFM to get their control signals down the arms to the end stations.)

For instance, the delay measurement in elog 9881 (c1als to c1lsc via dolphin) shows only the c1lsc model's own 61 usec delay. If the dolphin transfer really took an additional cycle, you would expect 122 usec.

And in elog 10811 (c1scx to c1rfm to c1ass), the delay is 122 usec, not because the RFM itself adds delay, but because an extra model is traversed.

Bottom line: there may still be some DARM phase unaccounted for. And it would definitely help to bypass the c1rfm model, as suggested in 9881.

To use instafoton, right click an MEDM screen, open the Execute menu, and choose "Foton".  Then click on the EPICS channel of a filter module as displayed on the screen.

Here's how it was set up:

• Install instafoton.py in /opt/rtcds/caltech/c1/scripts; edit paths to localize for the 40m
• Add instafoton to the MEDM_EXEC_LIST environment variable, newly defined in /ligo/cdscfg/workstationrc.sh:
  export MEDM_EXEC_LIST="Edit this screen;medm &A &:Probe;probe &P &:Foton (Pick filter PV);/opt/rtcds/caltech/c1/scripts/instafoton.py &P &"

After recompiling medm with a patch for dumping screens (attached), I added a time machine to the right-click Execute menu.  It's installed under /cvs/cds/caltech/users/wipf/src/medm_time_machine. Dependencies include the python CA server module (pcaspy) and the latest nds2-client 0.11.2.  These were also installed under my users directory, to avoid interfering with other tools.

The frontends have some paths NFS-mounted from fb. fb is on the ragged edge of being I/O bound. I'd suggest moving those mounts to chiara. I tried increasing the number of NFS threads on fb (undoing the configuration change I'd previously made here) and it seems to help with EPICS smoothness -- although there are still occasional temporal anomalies in the time channels. The daqd flakiness (which was what led me to throttle NFS on fb in the first place) may now recur as well.

(Steve, Chris)

The pumpdown had stalled because of some ancient vacuum interlock code that prevented opening the valve V1 between the turbo pump and the main volume.

This interlock [0] compares the channels C1:Vac-P1_pressure and C1:Vac-PTP1_pressure, neither of which is functioning at the moment. The P1 channel apparently stopped reading sometime during the vent, and contained a value of ~700 torr, while the PTP1 channel contained 0. So the interlock code saw this huge apparent pressure difference and refused to move the valve.

To bypass this check, we used caput to enter a pressure of 0 for P1.

[0] /cvs/cds/caltech/state/from_luna/VacInterlock.st

Attached is the version of the wiper script we use on the CryoLab cymac. It works with perl v5.20.2. Is this different from what you have?