40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 188 of 346  Not logged in ELOG logo
ID Date Authorup Type Category Subject
  5902   Wed Nov 16 01:45:37 2011 ZachUpdateelogrestarted

Elog was hanging. Restarted it with script.

  5926   Thu Nov 17 14:38:16 2011 ZachUpdateRF SystemStochmon?

It turns out that we don't have all the parts I would need to do a full prototype of the precision temperature controller. I am guessing that we won't want to sit around and wait for the parts given the upcoming TAC meeting, so I'll do the next best thing:

  • Standard DC temperature readout using an AD590.
  • More-or-less complete heater driver

Does anyone have a suggestion for how this thing will be packaged? I.e., should it be in a box or should it be mounted in a rack, etc. In the end, a real board will be printed and stuffed, so this need not be a really professional job in the short term.



Is there an update on Stochmon?  Are the signals acquired somewhere already?  What's the current deal-io?  The new EOM mount should be here later today, and I'm jazzed to start checking how my EOM box helps (hopefully) the amount of RFAM we see. 

I'll start making the adapter plate while I wait...


  5936   Fri Nov 18 00:25:10 2011 ZachUpdateelogrestarted

 with script.

  5937   Fri Nov 18 00:36:23 2011 ZachUpdateGreen LockingY-Arm PDH box modified

I modified the Y-Arm PDH box (S/N 17) to have the same TF as the one of the temporary setup described in Kiwamu's earlier entryNote that the TF below was taken with the gain knob set to 0, so that the proper DC gain is achieved with a setting of ~4. This is desirable because it gives us wiggle room.

The changes were:

  • R14: 25 -> 50
  • R29: 1k -> 10.5k
  • R30: 1k -> 20k
  • R28: 102 -> OMIT
  • C20: 84nF -> OMIT
  • R31: SHORT -> 475
  • R16: 10k -> 48.7k
  • R24: 10 -> 5

Below is the TF along with the LISO model. They are different at low frequencies because the box must have been railing internally (though the phase shows that the result is as expected), and there is a feature around 60 kHz that probably arises from some op amp instability. I will see if adding a small cap somewhere does the trick, and then take a new TF with a lower source voltage.


I'll try to lock the arm with the box tomorrow.

  5946   Fri Nov 18 12:11:24 2011 ZachUpdateGreen LockingY end green PDH servo : it's okay



 Another way to make a 1:100 pole:zero boost is to use resistors and capacitors in a Pomona box 

mixer -> LB box -> Pomona box -> PZT

Pomona Box =     R1 = 7.2 kOhm, C2 = 22 uF, R2 = 72 Ohms     (sr560 = $2400, pomona ~ $50)


For the RMS calculation, it would be good to notch out the harmonics. They don't matter since our ALS feedback will have notches at those frequencies.

I wouldn't bother...

  5954   Sat Nov 19 00:09:02 2011 ZachUpdateRF SystemFoam house on EOM


I used aluminum tape to attach the sensor and heater to the 40m's EOM, and we plugged in the controller.  It seems to be kind of working.  Zach figured out the GPIB output stuff, so we can talk to it remotely. 

I stole the Prologix wireless GPIB interface from the SR785 that's down the Y-Arm temporarily. The address is (Incidentally, I think some network settings have been changed since the GPIB stuff was initially configured. All the Prologix boxes have 131.215.X.X written on them, while they are only accessible via the 192.168.X.X addresses. Also, the 40MARS wireless router is only accessible from Martian computers at

In any case, the Newport 6000 is controllable via telnet. I went through the remote RTD calibration process in the manual, by measuring the exact RTD resistance with an ohmmeter and entering it in. Despite this, when the TEC output is turned on, the heating way overshoots the entered set temperature. This is probably because the controller parameters (gain, etc.) are not set right. We have left it off for the moment.

Here are a couple command examples:

1. Turning on the TEC output 

nodus:~>telnet 1234
Connected to
Escape character is '^]'.
++read eoi
2. Measuring the current temperature
++read eoi
3. Reading and then changing the set temperature
++read eoi
TEC:T 35.0
++read eoi
4. Figuring out that the temperature is unstable and then turning off the TEC (this is important)
++read eoi
++read eoi
(The "++read eoi" lines are the commands you give the Prologix to read the controlled device output.)
As I understand, Frank has some code that will pull data in realtime and put it into EPICS. This would be nice.
  5955   Sat Nov 19 00:34:36 2011 ZachUpdateRF Systemwhy the Newport 6000 isn't working

 I just figured out why the Newport 6000 isn't stabilizing the temperature. It is designed to drive a TEC, so that when the temperature is too high, it just applies a negative current. Of course, this doesn't work with a resistive heater; it just keeps heating it up more.

I'm not sure if Frank has actually used this with a restive heater before, but it doesn't appear that you can limit the low-current level or add an offset.

  5956   Sat Nov 19 00:47:24 2011 ZachUpdateGreen LockingY-Arm locked with PDH Box #17

I installed the newly modified PDH box #17 and locked the Y-Arm.

I wasn't able to bring the REFL level down to the 30% that Kiwamu claimed to get, despite readjusting the alignment---I got ~40-45%. I attained a UGF of ~8 kHz, lower than the 20 kHz that Kiwamu said he got with the temporary setup, probably because the PDH box just isn't as fast. Despite that, it looks like the error suppression is actually better than before...

Here is an error spectrum:


I have to admit that this calibration is worthy of suspicion and should be done more rigorously. I simply used the measured UGF frequency and known servo TF and PZT actuator gain to estimate the optical response. I am pretty confident that it's accurate to within a factor of 3 or so.

  5976   Tue Nov 22 06:12:43 2011 ZachUpdateRF SystemPrototype temperature controller

Tonight I built a simpler version of what will be the new general-purpose precision temperature controller. This one is built on a breadboard and will be used for RFAM testing at the 40m until a better version is made. Some  differences between this version and the final one:

  • In the interest of time, this controller senses temperature using a DC wheatstone bridge, instead of the audio-frequency bridge of the final controller.
  • I eschewed the more complicated transistor current source in favor of a simple current buffer. In effect, using a constant-current source is not absolutely necessary, since we are not interested in constant current but rather a constant system temperature. In this sense, it doesn't matter if we have a transistor current source or a transistor voltage source or a current-buffered op amp voltage source; the loop will simply drive the heater with the proper current to keep the error signal nulled. 

So, how it works:

  1. The DC bridge drive voltage is supplied by a voltage-divided and buffered AD587 (low-noise 10-V reference).
  2. The reference resistors are just 1% metal film leaded resistors, but I have put some effort into making them quiet:
    1. Each resistor's body is wrapped in Al tape, and then all the resistors are taped together using Al tape, as well. This is to strongly couple them to each other thermally.
    2. All the reference resistors are embedded in some foam I found in the Bridge sub-B hallway. It's nothing fancy, but it keeps large advection currents from causing thermal drifts.
  3. The sensing element is a PT100 100-ohm RTD. Tempco is ~0.0037 1/K
  4. The bridge differential voltage is read out by an AD620 instrumentation amplifier with G = 100
  5. The AD620 output is fed directly to an OP27 with G = 0-20
  6. This is fed to an LF356 (FET-input op amp, to reduce the effects of bias current when the integrator is on) with a single pole at 0.1 Hz, switchable via jumper to DC for true integration
  7. This is summed with an offset via an OP27 summer (the offset determines the heater current with no signal---half the maximum current of ~120 mA is optimal)
  8. The summer output is buffered with a BUF634, which can provide well over the maximum current we can push through our heater, and the BUF634 directly drives the heater
  9. Between the BUF634 and the heater is a back-biased diode to ground. This is to prevent the current from going negative when the error signal is well below zero.

I have tested the circuit using a spare resistive heater and a potentiometer to simulate the RTD. First I tested the sensing and drive circuits separately, then I connected the sensor output to the drive input and modulated the potentiometer resistance while monitoring the current. The circuit behaved as expected.

When I got to the 40m, it struck me that the resistance I had chosen (115 ohms) corresponded to 40 C, which I realized might be above what we could reach with the current we can provide. I used the Newport 6000 via telnet to drive the heater at several current values and see what the resistance became. I found that with I = Imax/2 ~ 0.6, the resistance was around 113 ohms (it was ~111 at room temp). So, I switched the reference resistor in the leg above the PT100 from 115 -> 113.

I then plugged everything in while monitoring the heater current and AD620 output (error signal), and it seemed not to do anything. I was tired so I figured I'd leave it for tomorrow.

Here is a sketch of the schematic, as well as some pictures:



  5983   Wed Nov 23 00:00:53 2011 ZachSummaryGreen LockingSome issues on the Y end green PDH locking


(AM transfer function)

 One of the suspicious noise source of the Y arm ALS was an AM effect in the Y end green PDH locking.
A possible scenario is that: there is some amount of the offset in the PDH signal due to the AM at the modulation frequency,
and it allows the intensity noise to couple to the laser frequency, which we want to suppress.
 So we wanted to check if the measured AM (#2799) at 1064 nm  is still true at 532 nm.
The problem right now is that : every time we measured the AM transfer function by exciting the laser PZT with swept sine,
the transfer function varied by 20 dB, with average response of 50 dB. And there was no repeatability.
We were using the PD which is for the green PDH signal and the single-bounced light from ETMY.
The measurement was done in a frequency band of 100 - 400 kHz where we expect a couple of sharp notches.
Perhaps we should try the same measurement with IR first to make sure we are doing a right thing, and then do it with the frequency-doubled laser.

What is meant by the "average response of 50 dB"? Is this dB[ RIN / Hz ] or something? Also, do you mean the average over a broad band or the average response at the chosen modulation frequency over several trials? I don't really understand what measurement was done.

  5984   Wed Nov 23 00:30:14 2011 ZachUpdateRF SystemEOM temperature controller trials

[Jenne, Zach]

We did some testing of the prototype temperature controller. When I left it late last night, it was not working in conjunction with the real heater and PT100 mounted to the EOM, but had been tested using simulated loads (a spare heater and a potentiometer for the RTD).

We measured each of the reference resistors carefully, as I should have done in the first place since they are only 1% tolerance (I am using 100-ohm ones in series with ~15-ohm ones, so they have a variation of +/- an ohm or so, which is consequential). We calculated the estimated zero-signal resistance of the RTD, then used a trimpot to verify that the AD620 output behaved as expected. We realized that I didn't tie the 620's reference to ground, so the output was floating around by a lot. Once we did that, the readout was still not working properly, but eventually magic happened and we got an appropriate signal. I did find that there was a discrepancy between the estimated zero-signal resistance and that measured across the trimpot with the readout nulled---this may be caused by a small offset in the 620, but is not important so long as the output still scales properly.

Before trying it out again on the real McCoy, I tested the whole, closed-loop circuit with the spare EOM on Jenne's desk. The temperature oscillated at first, but a reduction of gain at the input stage of the driver allowed it to stabilize. The temperature of the EOM (sitting on the electronics bench) was kept constant with a control current that varied from ~40 - 70 mA, depending on how many people were around it, etc. This is pretty much perfect for the quiescent level, but that means that we might have to increase the baseline operating resistance of the PT100 (by changing the reference resistors) once it is sitting in a hot foam box. Otherwise, we will have no gain on the cooling side. I tested the circuit response by cupping my hands over the EOM to increase the temperature and ensuring that the current dropped so as to null the error signal. It worked pretty well, with a thermally-limited bandwidth of I would estimate around 0.1 Hz. 

I went to try it out on the PSL table, but again it didn't work. It turned out that this time I had broken one of the soldered connections from the broken-out D-sub cable to the (tiny) wires going to the PT100, so there was no temperature signal. I resoldered it, but I forgot that there is a thin insulating layer on the wire, so no connection was made. Frank tutored Jenne on how to properly strip these wires without damaging the core, but alas I didn't pay attention.

The RTD/heater/D-sub package lies in wait on Jenne's desk, where I have left an apologetic note. Once it is fixed, we should be able to finally hook it up for realz.

  5985   Wed Nov 23 00:30:55 2011 ZachUpdateelogsucks

Tried the script 3 times and it didn't come back. Pkill'd and then scripted. That worked.

  5987   Wed Nov 23 13:53:36 2011 ZachUpdateGreen LockingSensor noise

The in-loop Y-Arm error signal looks equal to the beat note noise divided by the Y-Arm OL gain in the broadband-noise region (>20 Hz), which would be the case if the loop was dominated by sensor noise here.

I would re-check the Y-Arm dark noise, or at least check for coherence between the Y-Arm error signal and the beat signal above 20 Hz. The input-referred PDH box noise should not be flat there according to the LISO model, but that might be worth checking, too.


  5998   Thu Nov 24 12:45:12 2011 ZachUpdateIOORFAMPD channels / EOM monitor channels added to DAQ

Jenne: The point you indicate for the heater monitor is a virtual ground--it will be driven to zero by the circuit if it's functioning properly; the readout should be done at the input pin (2, I think) to the BUF634.

Koji: This is odd, as I made a point of not attaching any clips directly to resistors for exactly this reason. I was also careful to trim resistor/capacitor leads so that they were not towering over the breadboard and prone to bending (with the exception of the gain-setting resistor of the AD620, which was changed at the last minute). At the end of the day, it is a breadboard circuit with Pomona "readout", so it's not going to be truly resilient until I put it on a protoboard. Another thing: I think the small Pomona clips are absolutely terrible, since they slip off with piconewtons of tension; I could not find any more regular clips, so I used them against my better judgment.

  6032   Tue Nov 29 02:09:15 2011 ZachUpdateRF SystemEOM temp stabilization fixed

I inspected the temperature stabilization circuit today to see why it wasn't working. It didn't make sense that it just kept railing the heater even though the error signal was negative (which should turn the heater current OFF).

It turns out that the LF356 (FET-input op amp) that serves as the filter stage for the heater driver was broken---I measured a full, railed positive output even though the input was negative. We didn't have any more LF356s, so I replaced it with an OPA604 (Burr-Brown FET-input), and all seemed to work fine.

Since we were having too much digitization noise, I also added a temperature monitor buffer using a non-inverting OP27 circuit with G=99. This makes the overall calibration ~7.6 V/K into the ADC.

Below is a time series showing that it is working. The circuit was turned on near the beginning, and you can see that the heater is railed at +10V until shortly after the error signal goes negative, at which point it adjusts and ultimately approaches a steady-state value of ~7.8V.


I have no figures to demonstrate this, but it seems that even with this 100x increase in monitor gain, the error signal is still below the ADC noise level. This could be because the ambient temperature fluctuations are just that small on timescales of less than a few hours. I'm not sure if we really need to be able to see the temperature noise level above a few mHz, but if we do we will have to find some way to increase our dynamic readout range. 

Also, Koji told me where he stashed the nice protoboards, so I will get onto transferring this circuit onto one ASAP. Since it is working now, I think I'll leave it until after the TAC.

  6035   Tue Nov 29 14:22:03 2011 ZachUpdateRF SystemEOM temp stabilization performance

I left the EOM stabilization running overnight, so we can finally see how the EOM temperature stabilization does over long periods of time.

Here are both long-term (~13-hr) and short-term (1-hr) trends of the EOM temperature and the heater drive level. From the long trend you can see that the heater departed the steady value of ~7.8V that I observed last night to accommodate the diurnal heating of the lab in the morning---the temperature was held near zero offset.

From the short-term trend, there are 2 things to notice:

  1. We are still very close to the digitization noise level for both signals. This is bad, because we want to look at the residual noise level, etc.
  2. There appears to be some strange sort of disturbance of f~0.01-0.02 Hz. I'm not sure what causes the strange shape

Screen_shot_2011-11-29_at_1.33.50_PM.png Screen_shot_2011-11-29_at_1.34.06_PM.png


Finally, here is a trend over the last ~24 hours of the EOM temperature, heater drive level, and the 11- and 55-MHz Stochmon signals. I believe that the abrupt shelves noticeable on the Stochmon trends are when c1sus was turned on and shut down, respectively (I'm not sure why that causes the signals to die, but the times seem right, and nothing obvious happens to the EOM temp stabilization signals at either time). The controller was turned on at ~8:40 UTC, and you can see that the Stochmon signals quiet down a lot right at that time. There is some residual drift (common-mode to both RF frequencies), which is most likely caused by a drift in some other parameter (e.g. laser frequency or power).


I took some relatively inconclusive power spectra and coherence measurements, but I'd rather wait until we have an uncontrolled data stretch with which to compare. I think what we should do now is disconnect the controller and then let it sit for a while.


  6040   Tue Nov 29 18:17:27 2011 ZachUpdateRF SystemEOM temp stabilization performance


 It is not obvious what is working.


It should be. As I mentioned, you can only trust the Stochmon signals between 0840 and 1130 UTC; before this time, the temperature controller was not connected, and after this time, c1sus is shut down and the MC is not locked, as you can see in your DV plot.

Within this time frame, the Stochmon signals are relatively stabilized (though there is some residual common-mode-ish drift since we are not using RFAM as the error signal---i.e., other things like laser power and frequency can mix in). Also, anytime after 0840, the controller signals behave as they should (these are unaffected by the status of c1sus):

  • The EOM temperature signal (error signal) is stabilized to a value very near zero
  • The heater drive signal (control signal) moves around in such a way as to null the error signal, and you can confirm that it looks roughly like the opposite of the FSS_RMTEMP signal, as it should.

I am concerned with the other issues that I mentioned in my previous post, namely:

  1. Error signal dominated by digitization noise above some low frequency despite 100x amplification
  2. Strange ~0.01-Hz level disturbances in error signal.
  6043   Tue Nov 29 19:08:53 2011 ZachUpdateRF SystemEOM heater disconnected

I disconnected the heater at ~2:20 UTC, leaving the sensor circuit operational. Don't be fooled by the apparent railing of the heater in the monitor trace below---the heater has been physically disconnected, so there is no current flowing even though the servo is railed (since the error signal is huge with the loop open).

Kiwamu and I also restarted c1sus and locked the MC so that we can get some uncontrolled Stochmon data. I think he is planning to reconnect the heater some hours from now so that we can get yet another controlled data stretch (since the first one was cut short by c1sus's going down).


  6047   Tue Nov 29 23:03:34 2011 ZachUpdateRF SystemRFAM fluctuation reduced

I was hesitant to claim that this is definitely true without the control data we were taking after the heater was turned off today. This is because before I replaced the malfunctioning op amp last night, the heater was actually ON and injecting temperature noise into the system that would not be there with it off. I think the best idea is to compare the data from today (heater on vs. heater off, but with functioning circuit).



Indeed the fluctuation of the RFAM became quieter with the temperature control ON.

  6053   Wed Nov 30 13:52:09 2011 ZachUpdateRF SystemEOM temp stabilization ineffectual

This recent off/on run proved what I was afraid of: the temperature stabilization setup appears to do nothing except very near DC. The plot that Kiwamu posted is misleading because the "uncontrolled" data stretch at the beginning actually had the heater injecting random noise (since the circuit was broken). Below are some plots (sorry in advance for their crappiness---the plot tools wouldn't let me print to file for some reason):

Time series of the temp monitor, the heater monitor, and the 11- and 55-MHz RFAM monitors. The heater was disconnected at ~2:20 UTC, and the temperature is seen to equalize to the surroundings (note that the TEMP_MON is inverted, so positive change means decreasing temperature). The heater was reconnected by Kiwamu around 10:40 UTC, and you can see the temperature being driven back to the zero point by the loop. Note that the temperature was still decreasing at a fair rate when the heater is re-engaged---this could mean that we really need to take longer samples.



Spectra and coherence of the 11- and 55-MHz RFAM monitors before and after the control was re-engaged. It appears that the 11-MHz signal is unaffected while the 55-MHz signal actually gets worse. This also seems evident from the noisiness in the time series for that signal above (top right). Bad, bad, bad. 



Spectrum of the EOM temperature signal before and after control was re-engaged. There seems to be no change whatsoever. Of course, as mentioned before, this signal seems to be close to the digitization noise level as seen in DV. I am not sure what the ADC noise looks like at these low frequencies. In case someone knows, the magnitude of this signal in counts is ~0.1 ct/rHz at 10 mHz; is this too low? Another thing to note is that the noise level in K is pretty low! I would be surprised if the RTD can really see 10 uK/rHz at and below 10 mHz.




I need to try and increase the gain of the servo to see if I can get it much higher without it becoming unstable.

  6055   Wed Nov 30 22:09:20 2011 ZachUpdateRF Systemsome final EOM stabilization efforts

First, things that were done:

  • I was troubled by the odd-looking noise in the EOM temperature signal, so I investigated the circuit with a probe and found that there was quite a bit of line pickup, which I traced to the wires going to and from the RTD (if I placed a dummy resistor directly on the board, it went down markedly).
    • I put a 3-Hz RC LPF between the AD620 and the driver input buffer, which reduced the line noise significantly
    • The error signal looks much cleaner and there are no longer strong peaks in the error spectrum at ~1+ Hz and harmonics
  • I had tried earlier to increase the gain of the servo at the driver input stage. It seemed to stay stable. Since I knew the error signal  with the loop closed was at the level of the ADC noise, I decided to push my luck with increasing the servo gain and juice up the AD620 gain from 100 to 990.
    • The servo stayed stable and the error signal level is now manageable.

Things that I noticed:

  • With the latest increase in gain, I measured that the error signal was suppressed with the loop closed (the suppression is below ~0.1 Hz, and the reason that the high-frequency level is different is because it has been amplified above the ADC noise by the time of the second trace).


  • Despite the above, the Stochmon signals remained unchanged no matter what I did. I noticed that the Stochmon signals, too, were fluctuating basically at bit-level. I terminated the 11-MHz signal and compared it to the normal level---it is not exactly the same, but only a factor of 2-3 lower, which is not great. Of course, the RMS detector is logarithmic, but I think we still want the dark noise to be at least an order of magnitude lower here.
    • I tried to amplify the signal with an SR560, but since the DC level is supposed to be ~1-2 V, I could only get about 2x gain---not enough.



I think there are two things that could be happening here, given the above information:

  1. We are limited by the noise of the temperature sensing circuit, which would explain why the in-loop error signal is suppressed while the RAM levels appear not to be. This should be easy enough to test (though there's not enough time right now) with an out-of-loop sensor.
  2. The RAM is not dominated by temperature noise here. With the loop open, one would expect to see coherence between the RAM signal and the temperature sensor, if indeed one was the cause of the other. Instead, we see that---while the 11- and 55-MHz signals ARE pretty coherent with each other---there is no appreciable coherence between the temperature and the Stochmon signal.
  6059   Thu Dec 1 12:27:51 2011 ZachMetaphysicsRF SystemRAM diagnosis/suppression plan?

It seems like there is some confusion---or disagreement---amongst the lab about how to proceed with the RAM work (as Rana mentioned at the TAC meeting, we will henceforth refer to it only as "RAM" and never as "RFAM"; those who refuse to follow this protocol will be taken out back and shot).

I would like to provide a rough outline and then request that people reply with comments, so that we can get a collective picture of how this should work. I have divided this into two sections: 1) Methodology, which is concerned with the overall goal of the testing and the procedure for meeting them, and 2) General Issues, which are broadly important regardless of the chosen methodology.

1. Methodology

There are two broad goals:

  • Characterization of extant RAM
    • Measuring the RAM levels existing in an aLIGO-type interferometer without any suppression systems
    • Modeling to estimate the effect on IFO control and corroboration with measurements where possible
      • DC RAM levels contributing offsets to IFO operating point
      • Quasi-DC RAM levels affecting long term detector tuning (e.g., sensing matrix, MICH -> DARM feedforward, etc.)
      • Audio-frequency RAM contributing noise directly via error point modulation
    • Modeling to scale/adapt results from 40m -> aLIGO
  • Mitigation
    • Developing and assessing systems for suppressing RAM
      • Passive: thermal shielding and isolation
      • Active: EOM temperature control
        • Simple temperature stabilization
        • RAM error signal

The question is: which is our goal? The first, the second, or both? If both, what priority is given to which and can/should they be done in parallel? Also, task distribution.


2. General Issues

These are loosely related, so they are in random order:

  • Sensing
    • Temperature
      • What is the priority/urgency of a precision AC-bridge-readout temperature sensor?
      • If priority/urgency is low, what is the priority/urgency of upgrading breadboard controller to protoboard version? The common answer will be "make the protoboard version now", but if the urgency of the final AC sensing is high, it may make sense to focus on finalizing that design (after all, other experiments are waiting on a precision temperature controller, and it is not cost-effective to make many temporary controllers as I have done for the 40m).
      • Sensor noise issues
        • What is the sensor-noise-limited temperature stabilization level?
        • What is our willingness to tolerate the thermal low-passing of the EOM can itself (i.e., what is our sensitivity to gradients)?
        • To answer the above questions, we need to perform stabilization tests with several sensors on the same can, with some in loop (averaged) and some out of loop.
        • If we determine that gradients are a problem, we may need to:
          • Design a casing for outside the EOM (inside the foam box) to make the heating uniform, or
          • We may be able to get away with a more customized heater (instead of heating the can from one side as we do now).
    • Optical RAM
      • Stochmon is a nice diagnostic tool, but do we want something better? In particular, we want to have linear signals about a zero-DC-RAM point, which requires phase
        • Where will this sensor be located?
        • What kind of PD will it be? Broadband? Multi-resonant?
        • What sort of electronics will we need? If we are going to use this as an error signal for controlling the EOM temperature, it is just as important as any other IFO readout, since it may couple into all of them.
          • RF pickup is a BIG ISSUE HERE
          • How will the demodulation phases be selected? It should be possible to take TF measurements in certain misaligned (i.e., non-resonant) conditions and adjust the relative phase between the RAM readouts and standard IFO RF readouts such that they are in phase, but this will require some thinking.
          • Lots more, I'm sure
  • Control
    • Method (overlaps some with methodology portion)
      • What is better, simple temperature stabilization or RAM feeback? (More likely, "how much better is RAM feedback?")
      • If RAM feedback is difficult or impossible to implement effectively (see below), is temperature stabilization good enough?
    • Regime
      • Depending on extant RAM levels and on achievable sensing noise, it will be unwise and/or unnecessary to have a RAM control bandwidth above some relatively low frequency (~sub Hz)
        • Gain where RAM suppression is not needed only injects noise into the system
        • This cutoff frequency is largely determined by the thermal response of the system, but additional filtering will likely be necessary to reduce higher-frequency noise coupling (e.g., nonlinear downconversion of high-frequency signals into heater dissipation, etc.)
    • Efficacy
      • If we do RAM feedback, which signal (i.e. which frequency and quadrature) do we minimize?
        • Do we achieve large common-mode reduction across all RF signals, or is there some differential component?
        • In particular, do we make some or all other control signals noisier by stabilizing/minimizing RAM in one channel?
        • If the answer is yes, can we derive an effective control signal from a linear combination of some or all individual RAM signals?


There are probably many other issues I have neglected, so please comment on this rough draft as you see fit!

  6069   Mon Dec 5 09:46:21 2011 ZachMetaphysicsRF SystemRAM diagnosis/suppression plan?

Since no one has made any comments, I will assume that everyone is either 100% satisfied with the outline or they have no interest in the project. Under this assumption, I will make decisions on my own and begin planning the individual steps in more detail.

In particular, I will assume that our goal comprises BOTH characterization of RAM levels and mitigation, and I will try to find the best way that both can be achieved as simultaneously as possible. 

  6087   Thu Dec 8 01:26:31 2011 ZachUpdateRF SystemEOM temp sensor modified

I have modified the EOM temperature sensor circuit for the temperature vs. RAM long-term measurements. The only real change is that the sensor is a 100-kOhm thermistor, instead of a 100-Ohm RTD. These semiconductor thermistors (DigiKey P/N 317-1377-ND) are highly nonlinear and can be much more responsive than RTDs, but this difference is much more noticeable at low temperatures.

Frank had told me that the fractional response of the thermistors was so much higher that I could scale the bridge drive current down by the same factor as the resistance was increasing (i.e., 1 mA -> 1 uA, commensurate with 100 ohms -> 100k) and still see a marked improvement. It turns out that at room temperature for this particular sensor the gain enhancement would only be about ~10x, so I only reduced the drive current to ~10 uA, by INCREASING the drive voltage from ~0.1 V -> 1 V, improving the enhancement to ~100x.

Below is a plot of the real nonlinear response of the thermistor, along with a linear approximation at 298.15 K, which gives a coefficient of ~ -4.67 kOhms/K. The differential bridge output voltage response for the new resistance and current is ~7.5 uV/Ohm 2.5 uV/Ohm, bringing the total temperature response before amplification to ~35 mV/K 11.6 mV/K. Looking at a trend of the FSS_RMTEMP channel over a month, we saw that the maximum PSL table temperature fluctuations were ~2 Kpp, so we aimed the maximize resolution by matching +/- 2 K with +/-10 V at the ADC. This was done by using a gain of ~300 in the AD620 that amplifies the differential bridge output. We found that a gain of ~300 put it pretty close, so the grand total calibration ~ 10.5 V/K 3.5 V/K.

Edit (ZK): I screwed up with calculating the bridge response by a factor of three somehow, so I have stricken and restated the calibrations above




I took a look at the recently acquired temperature data alongside the RAMmon 11 and 55 signals, and it appears that we're seeing the same sort of fringing effects we usually see, with oscillatory RAM levels for a monotonic change in EOM temperature.The odd bit towards the end is caused by the MC losing lock. 

It is going to be very interesting to find out what causes this fringing.


  6088   Thu Dec 8 11:59:53 2011 ZachUpdateRF Systemfringing indeed

Here is a trend of 11 & 55 I&Q, along with the EOM temperature and PSL RMTEMP signals. You can see that there is definitely some fringe-like behavior for monotonic changes in temperature. This is consistent with what I have seen on the gyro table in the past.

Some other notes:

  • The EOM temperature (or at least the sensor temperature) seems to track RMTEMP almost exactly when there is no foam box on the EOM. I have verified that the max-min swing here is the same for both signals (~0.77 K).
  • Something crazy appears to happen at ~10:15, and all the RAM signals get much noisier. Does anyone know what happened at this time (2:15am local)?

We ought to get to the bottom of the fringing. The CTE of LiNbO3 is ~2 ppm/K, so given that the wavelength is on the order of 0.5 K, this is probably not caused by the etalon effect (2ppm/K * 0.5K * ~1cm << 1064nm).


  6101   Fri Dec 9 20:03:57 2011 ZachUpdateRF SystemLots of current used in Rich's demod box

D0902745-v5 (probably the AP1053's):



Those asymmetric currents are same as what I saw with the table top +/-18V supply. If you really don't like it, there could be an option to disconnect CH3/4 in the box.

In any case, this could be a good long-run test of the demod box, couldn't it?


I checked the power regulators on the Rich demod box (according to the schematic, D1000217).  The positive one is LM2941CT, and the negative one is LM2991T.  Both accept input voltage up to +26V or -26V respectively.  So my use of +\- 24V to be regulated down to +\- 15V isn't too crazy.  It's a little crazy, but not too crazy.  They recommend having only a 3V difference between the input and output voltages.  We don't have any 18V or 20V power supplies in the regular LSC power supply rack, so Rana suggested using the 24's. 

When I plug in and turn on the Rich box, the current on the +24V power supply goes up by about 0.8A, and the -24V supply goes up by about 0.3A.  That seems like kind of a lot.  Is that too much?  Do I need to find a better plan that involves +\- 18V?  Thoughts?

For now, the Rich box is off, just in case.



  6113   Tue Dec 13 16:31:40 2011 ZachUpdateIOOPSL beam realigned into MC

The MC coupling had become re-shittified. As we need transmitted MC light for the RAMmon, I realigned the input beam to the MC. (Jenne said that the MC mode itself should be well aligned, so I just used the zigzag on the PSL). MC_REFL is now ~0.5-0.6.

  6116   Wed Dec 14 12:18:11 2011 ZachUpdateRF Systemheater reengaged

I reengaged the heater this morning, to compare it with the free-wafting and passive box-covered data. In order to make the loop stable, I had to reduce the gain of the AD620 by 10. I have increased the TEMP_MON preamp gain by 10, so the calibration should still be ~3.5 V/K into the ADC (and in DV).

Below is a screenshot showing that the RAMmon signals are pushed to some (nonzero) value, and it appears that they stay there despite the changing PSL table temperature as measured by FSS_RMTEMP. My post from last week shows that without the heater servo the temperature of the EOM can follows RMTEMP almost exactly. So, it seems like the heater is working well at low frequencies, modulo sensor noise, which ought to be low for the thermistor. Since several things (MC, etc.) have changed since out baseline data, it migth be prudent to let this sit for a little while and then disconnect the heater to see what happens.


  6121   Wed Dec 14 16:19:46 2011 ZachUpdateRF SystemLO for new demod box

I'm not sure I agree with your conversions, BUT:

The IQ boards use a PE4140, fancy MOSFET array as the mixer, and according to Peregrine (manufacturer), they can be operated with 0-20 dBm LO drive. I'm not recommending we drive them at 0 dBm, but perhaps the numbers you mentioned are OK.


The Rich demod box wants 10dBm for the local oscillator inputs, so I measured the values that we have coming out of the distribution box.  I'm using the "Spare 55MHz" and the "POP11" outputs, both of which had terminators so were not in use. 

The 55MHz had ~600mV peak, so between 5 and 6 dBm. 

The 11MHz had ~800mV peak, so about 8 dBm.

This is not enough dBm for either.  Going in search of RF amplifiers now...


  6122   Wed Dec 14 18:06:39 2011 ZachUpdateRF SystemLO for new demod box

Actually, the LO inputs to the IQ boards have AP1053 (Cougar) amps on them. These are 10 dB amps and so putting 10 dBm in puts us on the very maximum of the LO range at 20 dBm.

I think the distribution box levels are fine. 


I'm not sure I agree with your conversions, BUT:

The IQ boards use a PE4140, fancy MOSFET array as the mixer, and according to Peregrine (manufacturer), they can be operated with 0-20 dBm LO drive. I'm not recommending we drive them at 0 dBm, but perhaps the numbers you mentioned are OK.


The Rich demod box wants 10dBm for the local oscillator inputs, so I measured the values that we have coming out of the distribution box.  I'm using the "Spare 55MHz" and the "POP11" outputs, both of which had terminators so were not in use. 

The 55MHz had ~600mV peak, so between 5 and 6 dBm. 

The 11MHz had ~800mV peak, so about 8 dBm.

This is not enough dBm for either.  Going in search of RF amplifiers now...



  6130   Sat Dec 17 11:53:46 2011 ZachUpdateSUSAborted Hysteresis test

Do you guys have timestamps for when you started/ended the test? I have been trying to take some long-term RAM data but keep getting foiled by stuff (this test, RTS upgrade, switching of RAMmon channels, etc.)


Quote from #6128

To test it, we are shaking all of the suspension biases +/-1.0 with a script.

The hysteresis test has been aborted.

All of the suspensions have accumulated unexpectedly big DC biases of about 5 from their nominal points.

In fact the ITMX and ITMY mirrors started being stacked to their OSEMs.
The script process has been force-quit and I have restored all the DC biases to their nominal points.
They still look okay: MC can be locked at the 00 mode, DRMI fringe is visible at AS, the green beams are resonating the arm cavities
Need another trial.


  6138   Mon Dec 19 23:50:23 2011 ZachUpdateRF SystemRAMmon

I have been looking at the swings in the RAMmon channels since the heater was reengaged, to compare them to the data from beforehand (with and without the foam box). With the large grains of salt that I will list after, it appears that the EOM temperature controller does in fact reduce the amplitude of the swings by a measurable factor.


  1. The reason I have not included any plots here is because the data suck. What we should ideally have is a continuous stream of RAMmon signals split into three chunks: 1) no foam, no heat, 2) foam, no heat, and 3) foam and heat. Instead, we have pieces of each kind of data on different days, before and after the MC has been realigned, some in old channels and some in new so that the calibration is different, etc. This piecemeal shit will not do.
  2. I realized that the LF boost was not engaged on the heater when I turned it on most recently. For this reason, the EOM temperature has not been stabilized as well as it might have been on diurnal timescales, and so with the boost it could be that the noise reduction is greater. For posterity, the DC suppression level is ~20x without the boost.

It seems impractical to try and rope off essentially 3 straight days where nothign major can be done to the IFO just to take RAM data. Instead, I think we should figure out a way to mimic the diurnal temperature swings on ~hour timescales. The EOM can temperature follows PSL-FSS_RMTEMP almost exactly and with a very short delay, so we can probably even accomplish this by stepping the lab A/C temperature. If this won't work, we can use an incandescent lamp or something similar to heat up the area around the EOM by a noticeable amount.

I'll try to come up with a good way to do this so that we can get some reliable data...

  6197   Fri Jan 13 17:40:38 2012 ZachUpdateRF Systemfoam box and temp controller taken off of PSL table

I stole the foam EOM box and the temperature controller circuit from the PSL table so that I could continue with the RAM measurements here at the ATF.

That is all.

  6219   Tue Jan 24 13:36:05 2012 ZachBureaucracyGeneralIf I'm Peter Pan...


JA - MIE - RO!

  6255   Fri Feb 3 23:19:22 2012 ZachUpdateSUSOSEM testing begins

I took one of the spare OSEM satellite amps (schematic) from the cabinet down the Y arm this afternoon to begin testing. I spent most of the day amassing the melange of adapters and connectors I needed to talk to the relic. The most elusive was the über-rare 64-pin IDE connector, for which neither the 40m nor Downs or Bridge had a breakout (despite there being several Phoenix boxes on each electronics rack at the 40m---hmm...). The solution I came up with was to make a breakout cable myself, only there was no 64-pin ribbon. So, I carefully fed a 50-pin and most of a 16-pin ribbon side by side into one push-down connector, and that was that:


I also finally found a 25-pin D-sub breakout just after figuring out the proper pinout for a 25-to-9 adapter, which I thought I was going to have to use. OH WELL.


The first thing I figured I'd do is measure the LED drivers' current noise and see how it compared with LISO. I powered the box up and found that the TO-3 7815 regulator was putting out +20V---bad. I assumed it was broken, so I got another one from Downs and replaced it. Powered it up again and the output was still at +20V (WTF?). My suspicion is that one of the shielding capacitors has failed in some bizarre way, but I didn't have time to check this before I was beckoned to another task. This is where I'll start again next.

Another thing Frank and I noticed as we were figuring out how the driver worked was that the current-specifying resistor of one of the driver stages had not been properly modified along with the others, so it was forcing the feedback loop to rail. This mod was done precariously by adding two perpendicular sandwiched "Radd" resistors on top of the main one, so it's also possible that the ones for this stage had just been knocked off somehow (perhaps by the massive gender-switching ribbon chain hanging down on it). Steve and I noticed that there was a label on the box complaining that some part of the amp for one of the OSEMs wasn't working, but we peeled it off and threw it away because he figured it was outdated.

Anyway, in short, the plan going forward is as follows:

  • For this box
    • Measure the LED driver and PD transZ amp noises with dummy components
    • Compare with LISO to make sure they make sense
    • Measure the noise again with an OSEM connected
    • Based on the above and more LISO modeling, decide if it's a good idea to replace the LT1125's with OP497's
    • Increase the dynamic range by allowing +/-10V output, rather than +/-2V as was needed for old ADCs
  • After
    • Systematically mirror the changes in all other boxes by switching one out at a time

Comments welcome.

  6258   Tue Feb 7 03:05:08 2012 ZachUpdateSUSOSEM sat amp measurements

I did some more investigation on the OSEM box today.


After removing some capacitors and still finding that the +15V rail was at over +20V, I decided to see if the TO-3 7815 that I removed behaved properly all by itself. It did. After some more poking around, I discovered that whoever assembled the board isolated the case of the regulator from the board. It is through the case that this package gets its grounding, so I removed the mica insulator, remounted the regulator, and all worked fine.

Since I had gotten a spare from Downs, I also replaced the LT1031 (precision 10-V reference), for fear that it had been damaged by the floating voltage regulator.


Noise measurements:


LED Driver

With the above out of the way, I was finally able to take some measurements. The first thing I did was to look at the LED drivers. I fixed the one stage that I mentioned in my last post by adding two 820-ohm resistors in parallel with the 1k, such that it was very close to all the others (which are 806 || 806 || 1k). With that, using a red LED, I measured a current of 34.5 mA (+/- 0.1) out of each of the 5 stages (UL, UR, LL, LR, S).

I then measured the current noise of each one by monitoring the voltage across the 287-ohm resistor in series with the LED. The driver works by putting the LED in the feedback path of an inverting amp. There is a 10-V input from the LT1031, and the values of the input and feedback resistors determine the current drawn through the LED. There is a buffer (LM6321) in the path to provide the necessary current.

The LISO model I made according to that description seems to make sense. I simply modeled the LED as a small resistor and asked LISO for the current through it. The transfer function shows the proper DC response of -49.15 dB(A/V) -->  34.8 mA @ 10 V, but, the estimated current noise doesn't add up with the measured levels:


I have to get to the bottom of this. Two possibilities are: 1) The buffer adds noise, and/or 2) I am modeling this invalidly.

PD Amp

I also began measuring the PD amplifier noise levels, though I only measured two of them for lack of time. I find it odd that there is a 100-ohm input series resistor on what I thought would be just a transimpedance amplifier. For that reason, I want to look into how the OSEMs are connected to this guy.

In any case, I measured the output noise of two of the PD amps by shorting the input side of the 100-ohm resistors to ground, and then I divided by their TF to get the input noise level. Here it is compared with the LISO estimate. I have plotted them in units of voltage noise at the input side of the resistors for lack of a way to infer the equivalent photocurrent noise level.


Above 2 Hz or so, the measured level agrees with the prediction. Below this, the measured noise level increases as 1/f, while it should go as the standard 1/sqrt(f) (the manufacturer-quoted 1/f corner is at 2 Hz). Another thing to get to the bottom of.

  6261   Thu Feb 9 12:38:15 2012 ZachUpdateSUSOSEM LED driver noise

Frank pointed out to me that I had dumbly forgotten to include the voltage reference's noise. The LT1031 has an output noise level of ~125 nV/rHz above 10 Hz or so, and this at least makes the estimate much closer. I had also not included an extra LT1125 stage between the reference and the other stages. I guess I was tired.


The estimate is now within a factor of a few of the measured level, and it has roughly the right shape. Around 1 Hz, it looks like the measured data begin to roll up away from the model, though it's tough to say due to the effect of the AC coupling on the analyzer less than a decade below. If there is indeed extra noise here, Frank thinks it could be due to resistor current noise.

I'll switch one or two out for nicer ones and see if things change.

  6267   Fri Feb 10 02:43:37 2012 ZachUpdateSUSOSEM LED driver noise *reduced*

I worked on the OSEM box a little more today, with the hopes of reducing the measured output current noise. I succeeded, at least modestly. It turns out that most of the noise was indeed caused by the crappy resistors.

Below is the circuit for one of the 5 LEDs. The output of the op-amp structure directly after the LT1031 reference is split between 5 stages identical to the structure on the right. I have shown just one (UR) for clarity. The various measurement points are explained below.


I started from the beginning of the circuit, directly after the LT1031, to make sure that the excess noise seen the other day wasn't just from a noisy reference. Below is the measured output voltage noise along with the LISO estimate. Clearly, the LT1031 is performing to spec (as it should, since it's a new part that I just put in). Note that the apparent better-than-spec performance at low frequencies is just from the AC coupling, which I needed due to the high DC level.


Since the reference was in order, the next step was to switch out some of the crappy old resistors for nicer thin-film ones. In case anyone is interested, Frank has done some detailed investigation of excess 1/f current noise in resistors. I measured the voltage noise level at the point labeled "inter-stage measurement" above, first without any modifications and then after swapping the old 10k resistors (R1 & R2) out for nice Vishay thin-film ones. There is clearly a big improvement, and the modified circuit essentially agrees with LISO now down to 1 Hz. Below this, it looks like there could still be an issue.


I wanted to see what the improvement was in the overall output current noise of the system, so I went about measuring the current noise as I had the other day (by measuring the voltage noise across R55 and dividing by the resistance). The performance was already better than the old measurement, but not at the LISO level. So, I replaced the current-setting resistors (R54 & R55)---which were actually 3 parallel resistors on a single pad in each case---by nice Vishay ones, as well. I didn't have any that were close to the original resistance of ~287 ohms, so I put three 1k ones in parallel. This of course shifts the resistance up to 333 ohms, but that only causes a ~16% change in current. I was sure to convert voltage noise into current noise with this new resistance, though.

With this change, the total output current noise is now very close to the LISO estimate as well down to ~1 Hz.


Some notes:

  • First, I apologize for the noise margin at higher frequencies. I redid the higher frequency measurements with an SR560 as a preamp, but I must have screwed up the calibration because the data don't match up quite right with the LF measurements. It was clear while I was taking them that they followed the LISO trace.
  • There still seems some excess noise below 1 Hz. It could be that the noisy resistors in the parallel stages were somehow still contaminating the cleaned-up channel. I'll look into this more soon.
  6307   Thu Feb 23 02:20:07 2012 ZachUpdateSUSwacky state of SUS input matrices

This reminds me that the whole Dr. SUS situation never got taken care of. Where I left off, I was having issues pulling 40m data with NDS2 (which is what all the diagonalization scripts use).

What is the deal with 40m+NDS2? If it is till no-go, can we have a consensus on whether this is too important to wait for? If so, I will rewrite the scripts to use NDS and we can upgrade to NDS2 once we can prove we know how to use it.



While Kiwamu and I were trying to investigate the the vertex glitches we were noticing excess noise in ITMX, which Kiwamu blamed on some sort of bad diagonalization.  Sure enough, the ITMX input matrix is in the default state [0], not a properly diagonalized state.  Looking through the rest of the suspensions, I found PRM also in the default state, not diagonalized.

We should do another round of suspension diagonalization.

Kiwamu (or whoever is here last tonight): please run the free-swing/kick script (/opt/rtcds/caltech/c1/scripts/SUS/freeswing) before you leave, and I'll check the matrices and update the suspensions tomorrow morning.


0.25 0.25 0.25 0.25 0
1.66 1.66 -1.66 1.66 0
1.66 -1.66 -1.66 1.66 0
0 0 0 0 1


  6399   Sat Mar 10 15:29:47 2012 ZachHowToComputer Scripts / ProgramsModeMatchr

For your mode matching pleasure, I have added a tool called "ModeMatchr" to the SVN under /trunk/zach/tools/modematchr/

It uses the usual fminsearch approach, but tolerates a fully astigmatic input (i.e., w0ix ≠ w0iy, z0ix ≠ z0iy) and allows for transforming to an elliptical waist  (i.e., w0fx ≠ w0fy, but z0fx = z0fy). It would be straightforward to allow for z0fx ≠ z0fy, but I have never seen a case when we actually wanted this. On the other hand, the elliptical output ability is nice for coupling to wide-angle ring cavities.

It also does the looping through available lenses for you , and retains the best solution for each lens combination in an output cell, which can then be combed with another function (getOtherSol). fminsearch is incredibly fast: with a 10-lens bank, it finds all 100 best solutions on my crappy MacBook in <10s.

I have also included the functionality to constrain the length of the total MMT to within some percentage of the optimal distance, which helps to sift through the muck .


  6415   Wed Mar 14 13:27:15 2012 ZachHowToComputer Scripts / ProgramsModeMatchr

I have added to ModeMatchr the capability to fix the total MMT distance. This is nice if you are coupling to a cavity some fixed distance away. The blurb from the help:

% Note: for any total length constraint dtot_tol > 0, ModeMatchr will use
% fminsearch to find the best solutions near your nominal dtot, and then
% omit solutions whose dtot lie outside your tolerance. For dtot_tol = 0,
% ModeMatchr actively constrains dtot to your value, and then finds the
% best solution. Therefore, set dtot_tol = 0 if you have a fixed distance
% into which to put a MMT.


For your mode matching pleasure, I have added a tool called "ModeMatchr" to the SVN under /trunk/zach/tools/modematchr/

It uses the usual fminsearch approach, but tolerates a fully astigmatic input (i.e., w0ix ≠ w0iy, z0ix ≠ z0iy) and allows for transforming to an elliptical waist  (i.e., w0fx ≠ w0fy, but z0fx = z0fy). It would be straightforward to allow for z0fx ≠ z0fy, but I have never seen a case when we actually wanted this. On the other hand, the elliptical output ability is nice for coupling to wide-angle ring cavities.

It also does the looping through available lenses for you , and retains the best solution for each lens combination in an output cell, which can then be combed with another function (getOtherSol). fminsearch is incredibly fast: with a 10-lens bank, it finds all 100 best solutions on my crappy MacBook in <10s.

I have also included the functionality to constrain the length of the total MMT to within some percentage of the optimal distance, which helps to sift through the muck .



  6443   Mon Mar 26 12:50:24 2012 ZachUpdateelogrestarted with script

On the plus side, it was the first time I've had to do it in a while..

  6478   Tue Apr 3 01:52:15 2012 ZachUpdateLSCRAM simulation for Full ifo


 I also would like to extend this script to use the DC readout, but don't know how to calculate the postion offset for AS_DC because the error signal is not zero-crossing for AS_DC anymore. Do you have any suggestions for me?

 I don't think I understand the question. AS_DC should not have a zero crossing, correct?

  6550   Thu Apr 19 16:21:04 2012 ZachUpdateComputer Scripts / ProgramsArbcav updated, made badass

I have modified Arbcav to be way cooler than it used to be.

Main modifications:

  • Can now truly model an arbitrary cavity geometry
    • The previous version could only handle a few different topologies. In each case, it would unfold the cavity into the equivalent linear cavity and use the g-parameter method to calculate gouy phases, etc.
    • The new model uses the closed cavity propagation matrix to find the supported mode, and then explicitly calculates the accumulated gouy phase by propagating the beam through the full cavity. This is done analytically with zR, so there is negligible slow-down.
  • Now plots a diagram of the cavity geometry, both to help you and for you to verify that it is calculating the right thing (<-- this is the cool part)
    • Plots the beam path and mirror locations
    • Specifies whether mirrors are curved or flat
    • Prints mirror parameters next to them
    • Finds all intracavity waist locations and plots them
    • Gives waist information (size in X, Y)

Since the information is already there, I will have the output structure include things like the input beam q parameter, which could then be fed directly to mode matching tools like ModeMatchr.

The function takes as input the same arguments as before. Example for a square cavity:

out = arbcav([200e-6 50e-6 200e-6 50e-6],[0.75 0.75 0.75 0.75],[1e10 9 1e10 9],[45 45 45 45],29.189e6,10e-6,1064e-9,1000);


out = arbcav(transmissivity_list, length_list, RoC_list, angle_list, modulation_freq, loss_list_or_loss_per_mirror, wavelength, num_pts_for_plot);

If you don't give it a modulation frequency, it will just plot carrier HOMs. If you don't give it RoCs and angles, it will just plot the transmission spectrum.


I'm still fine-tuning some functionality, but I should have it up on the SVN relatively soon. Comments or suggestions are welcome!


Some screenshots:

Cavity geometry plots (linear, triangular, square, bowtie):



Transmission and HOM spectra (these correspond to the square cavity at lower left, above):


  6823   Sat Jun 16 12:03:41 2012 ZachUpdateGreen Lockingscanned Y arm for 5FSR

Is that time stamp really correct? I wanted to look at the signal closely to see if I could get any feeling for why it would look so different when positive vs. negative, but I do not see a triangle anywhere near this time (1023780144)...


Interesting. It seems for me that there is a dependence of the noisiness as the beat frequency is scanned.

As you increase (or decrease?) the offset, C1:ALS-BEATY-COARSE_I_IN1 becomes bigger and more crisp.
The resulting out-of-loop stability also seems to be improved as you can see from the crispness of the PDH signal.

Do you find why this happens? Is this because the beat S/N depends on the beat frequency due to the PD noise?



  6912   Wed Jul 4 18:25:44 2012 ZachUpdateComputersNDS2 client now working on Ubuntu machines

After plenty of work, NDS2 can now be used to get site data within MATLAB using the following machines:

  • allegra
  • megatron
  • ottavia
  • pianosa
  • rosalba
  • rossa

What I did

NDS2 was not working on any of the machines, so the first thing I did was simply to install the newest version. I downloaded the latest tarball (0.9.1) from the LDAS Wiki, unzipped and installed it

/users/zach $ tar -xvf nds2-client-0.9.1.tar

/users/zach $ cd nds2-client-0.9.1

/users/zach $ sudo ./configure --prefix=/cvs/cds/caltech/apps/linux64 --with-matlab=/cvs/cds/caltech/apps/linux64/matlab/bin/matlab

/users/zach $ sudo make

/users/zach $ sudo make install


Even with the new version, it still didn't work.

Solution: The main problem was that the cyrus-sasl-gssapi authentication protocol was not installed on these machines, so that even with a kerberos ticket the datalink could not be established. Using information from the LDAS Wiki, I used aptitude to install it as:

$ sudo aptitude install lscsoft-auth

This group installs both the SASL protocol and the package python-kerberos


I also needed to update the kerberos config file for each machine, which is located at /etc/krb5.conf. I found that ottavia had a nice one with many realms, so I copied that one over to the other machines. In any case where there was an old config file overwritten, it is now /etc/krb5.conf.old.

Finally, the matlab path for NDS2 was still set to the old 2010a directory (/cvs/cds/caltech/apps/linux64/lib/matlab2010a) that was created by the NDS2 install when Rana originally did it. The new install I made above created the appropriate 2010b mexa64 files, so I changed the matlab path within matlab to this one:

>> rmpath /cvs/cds/caltech/apps/linux64/lib/matlab2010a

>> addpath /cvs/cds/caltech/apps/linux64/lib/matlab2010b

>> savepath


Now everything works fine on all these machines. As in Rana's original post, you get data in the following way:

$ kinit albert.einstein %then enter password

$ matlab -nosplash -nodesktop

>> d = NDS2_GetData({'H1:LSC-NPTRX_OUT16.mean'},963968415,6000,'nds.ligo.caltech.edu:31200')


d = 

            name: 'H1:LSC-NPTRX_OUT16.mean' 

            chan_type: 'm-trend'             

            rate: 0.0167       

            data_type: 'real_8'     

            signal_gain: 1   

            signal_offset: 0     

            signal_slope: 1     

            signal_units: ''   

            start_gps_sec: 963968415     

            duration_sec: 6000             

            data: [100x1 double]           

            exists: 1


>> quit % since you've seen that the data is really here

$ kdestroy % so that no one uses your credentials


Some thoughts

  • I would like to extend this to the 32-bit machines, but I have to figure out the best way to install the proper NDS2 client without interfering with the 64-bit version. I think it is just a matter of specifying the matlabroot in the .../linux/ instead of .../linux64/
  • It would be nice to find a way that the nice tool gps('MM/DD/YYYY XX:XX:XX UTC'), which calls the ligotool executable tconvert, can be automatically usable when calling NDS2 functions. Right now, there seems to be an issue preventing that: even though tconvert can be run in the terminal, gps() returns an error and even directly running unix('tconvert now') or !tconvert returns the same error. I have emailed Peter Shawhan to see if he has any advice.



  6921   Thu Jul 5 13:12:12 2012 ZachUpdateComputersNDS2 client now working on Ubuntu machines

From my conversations with JZ and Leo, it seemed there was no package that generated the appropriate mex files. It was clear that the right ones weren't there from the absence of a /cvs/cds/caltech/apps/linux64/lib/matlab2010b directory. I'm sorry if I screwed anything up with pynds, but I have repeatedly asked for help with NDS2+matlab and no one has done anything.

It would be nice to do it via apt if there indeed is a versioned package that can make the mexs. Sorry again if I jumped the gun, but I didn't think anyone was going to do anything.

I guess the only 32-bit machine I can think of is mafalda.

About tconvert, I think the best solution is to make a new wrapper M-file. gps was just a convenient remnant of mDV, but all that we need is some matlab function that can output a GPS time given a date/time string. We can use whatever command-line utility you want.

  7136   Thu Aug 9 12:55:15 2012 ZachUpdateelogelog was being a pain in the ass; I restarted it

The elog was not responding. I attempted to restart it by running .../start-elog.csh, but this didn't work (even after the usual ~2 times it needs).

Somehow pkill did not kill the daemon, so I kill -9'd it and that did the trick. I ran the start script once more and it came back online.

  7782   Tue Dec 4 11:30:36 2012 ZachUpdatePSLPMC calibration for MC_F calibration

In order to have less unknown, you can calibrate the PMC PZT separately. Lock the PMC and take a transfer function from either the NPRO PZT input or the FSS AOM VCO input to the PMC control signal. The VCO is better, since the calibration should be much better known, but I am not sure what the current setup of the 40m PSL is, so I don't know if the FSS is normally locked.

Since you know the NPRO PZT or VCO actuation coefficients, you can assume the PMC loop (where the OL gain is high enough) is correcting for the frequency fluctuations. So, simply multiply the known coefficient by the transfer function to get the PMC PZT gain.

Then, you can re-do your PMC PZT sweep measurement and be confident of the calibration. The FSR must be right, so you can get the finesse with confidence.


Hmm... Does anyone find falses in my measurement?
If not, the finesse can be 4 times smaller than the value which was 5 years ago?


  7965   Wed Jan 30 14:37:01 2013 ZachUpdateISSISS Design and Prototyping


Unfortunately, as noted in the file, not all of the elements are possible to analyze in liso, such as any type of op-amp with more than two inputs and one output (AD602 used in this design has 16 pins with two distinct amplifiers contained within).

Typically, you can still find a way to model the important parts of the stages that are not as simply added. In the case of the differential input stage, in particular, it is important to include it because it will usually set the input noise level of the circuit. In this case, the noise is the same as the second stage (U5) and it has a gain of 1, so there is essentially no difference (up to factors of sqrt(2) or 2).

You can edit the opamp.lib file and add in custom components. For the input stage, you can just pretend it is a simple non-inverting amplifier with the specified noise characteristics from the datasheet: un = 1.3n, uc = 50 Hz (see below).

For dual op amps, you can usually just model each part separately. For example, the OPA2604 is a dual op amp that is included in the opamp.lib and can be treated as a single one in a model.



ELOG V3.1.3-