40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 187 of 344  Not logged in ELOG logo
ID Date Authorup Type Category Subject
  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).

Quote:

 

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.

Screen_shot_2011-11-30_at_1.31.44_PM.png

 

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. 

Screen_shot_2011-11-30_at_1.29.48_PM.png

 

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.

 

Screen_shot_2011-11-30_at_1.21.16_PM.png

 

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

 EOM_temp_stab_and_unstab_new_11_30_11.pdf

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

 11MHz_wandwo_ctrl_and_adc_noise_11_30_11.pdf

Conclusion

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

 

 

100k_thermistor_response.png

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.

RAM_with_temp.png

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

RAM_with_temp_overnight.png

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

D0902745-v5 (probably the AP1053's):

Screen_shot_2011-12-09_at_8.00.54_PM.png

Quote:

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?

Quote:

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.

heater_reengaged_12_14_11.png

  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.

Quote:

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. 

Quote:

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.

Quote:

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:

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.

Salt:

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

jamie_rufio.png

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:

IDE64_homestyle.png

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.

Science

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.

Troubleshooting:

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:

sat_amp_measurement_setup.png

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:

LED_driver_vs_liso.png

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.

pd_amp_vs_liso.png

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.

LED_driver_vs_liso.png

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.

circuit.png

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.

LT1031_vs_liso.png

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.

interstage_vs_liso.png

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.

LED_driver_vs_liso.png

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.

 

Quote:

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]

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 .

MMrLogo.png

  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.

Quote:

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 .

MMrLogo.png

 

  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

Quote:

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

i.e.,

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

linear.pngtriangular.pnggyro.pngbowtie.png

 

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

gyro_spect.pnggyro_HOM.png

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

Quote:

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.

Quote:

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

Quote:

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.

Screen_Shot_2013-01-30_at_4.22.46_PM.png

 

  7966   Wed Jan 30 15:45:09 2013 ZachUpdateLockingMode spacing calc

Quote:

Thus, the modes should be well separated

=>  spacing is 4.3 MHz while FWHM is 0.311 MHz  (cavity fsr = 34.5 MHz)

Something looks fishy. I calculate a transverse mode spacing of 2.21 MHz---is there a factor of two missing somewhere in your analytical calculation?

delta_f = (1/2/pi) * w01 - w00 = (1/2/pi) * acos(±sqrt(0.96)) /pi *2 * pi * c /2 /L = 2.21 MHz

I guess that's still OK, but if you are using 11-MHz sidebands, there is a n+m=5 mode within one linewidth of resonance. Can you use 55?

-------------

May I suggest my arbcav() tool for things like this? I think it's pretty handy for just this sort of calculations. I'm actually hoping to revamp the I/O to make it much cleaner and more intuitive.

>> T = [0.055 20e-6];

>> L = [4.34 4.34];

>> RoC = [115.5 1e10];

>> theta = [0 0];

>> fmod = 11e6;

>> lambda = 1064e-9;

>> num_pts = 1000;

>> loss = 50e-6;

>> [fin,coefs,df] = arbcav(T,L,RoC,theta,fmod,loss,lambda,num_pts);

>> fmod = 55e6;

>> [fin,coefs,df] = arbcav(T,L,RoC,theta,fmod,loss,lambda,num_pts);

 

HOM11.png HOM55.png

  7975   Thu Jan 31 15:20:46 2013 ZachUpdateLockingMode spacing calc

I should mention that I just found a bug in how it treats odd-mirror-number cavities. For such cavities, HG modes with odd horizontal indices should receive an extra roundtrip phase of pi/2 (due to the rotation by the cavity). Because of a numbering convention issue, arbcav actually used to apply this phase shift to even-order modes. Essentially, the only difference is that the fundamental mode was shifted to anti-resonance. Everywhere else, there are modes at both corresponding locations in frequency space, and so it does not back a big difference in terms of cavity design.

Thanks to this IMC modeling we are doing at the workshop, I caught it! It has been fixed in the SVN.

Quote:

I have calculated (using Zach's sweet software) the expected mode content for the various possible PRCs that we can make. 

Also, Zach was right about the factor of 2.  I see now that I was calculating the mode spacing between a plane wave and a HOM, so the guoy phase had a factor of (n+m+1).  The right thing to do is to get the spacing between the 00 mode and HOMs, so the guoy phase just has (n+m).  Switching from n+m+1=2 to n+m=1, that fixes the factor of 2 problem.

 I attach my results as a pdf, since I'm listing out 5 configurations.  Each config has a cartoon, with a small (hard to read) HOM plot, and then at the end, each HOM plot is shown again, but larger.  Also, "TM" is the "test mirror", the flat G&H that we're using as the cavity end mirror.

 

  7982   Fri Feb 1 12:22:27 2013 ZachSummaryASCOptics lit

It's OK; even Siegman got it wrong---48 times.

RA: NO, stil not OK.

Quote:

 Gouy not Guoy:

http://www.rp-photonics.com/gouy_phase_shift.html

pronounced Goo-eee, with the emphasis on the second syllable.

 

  8097   Mon Feb 18 00:03:46 2013 ZachUpdateComputer Scripts / ProgramsARBCAV v3.0

I have uploaded ARBCAV v3.0 to the SVN. The major change in this release, as I mentioned, is the input/output handling. The input and output are now contained in a single 'model' structure. To define the cavity, you fill in the substructure 'model.in' (e.g., model.in.T = [0.01 10e-6 0.01]; etc.) and call the function as:

model = arbcav(model);

Note: the old syntax is maintained as legacy for back-compatibility, and the function automatically creates a ".in" substructure in the output, so that the user can still use the single-line calling, which can be convenient. Then, any individual parameter can be changed by changing the appropriate field, and the function can be rerun using the new, simpler syntax from then on.

The function then somewhat intelligently decides what to compute based on what information you give it. Using a simple option string as a second argument, you can choose what you want plotted (or not) when you call. Alternatively, you can program the desired functionality into a sub-substructure 'model.in.funct'.

The outputs are created as substructures of the output object. Here is an example:

 

>> th = 0.5*acos(266/271) *180 /pi;

OMC.in.theta = [-th -th th th];

OMC.in.L = [0.266 0.284 0.275 0.271];

OMC.in.RoC = [1e10 2 1e10 2];

OMC.in.lambda = 1064e-9;

OMC.in.T = 1e-6 * [8368 25 8297 33];

OMC.in.f_mod = 24.5e6;

>> OMC

OMC = 

    in: [1x1 struct]

>> OMC = arbcav(OMC,'noplot')

Warning: No loss given--assuming lossless mirrors 

> In arbcav at 274 

OMC = 

         in: [1x1 struct]

        FSR: 2.7353e+08

        Lrt: 1.0960

    finesse: 374.1568

    buildup: 119.6956

         df: [1000x1 double]

      coefs: [1000x4 double]

        HOM: [1x1 struct]

>> OMC.HOM

ans = 

      f: [1x1 struct]

    pwr: [1x1 struct]

>> OMC.HOM.pwr

ans = 

    carr: [15x15 double]

     SBp: [15x15 double]

     SBm: [15x15 double]

 

Some other notes:

  • The annoying Mdo.m has been internalized; it is no longer needed.
  • For the next release, I am working on including:
    • Finite mirror thickness/intracavity refractive elements - If, for god knows what reason, you decide to put a mirror substrate within a cavity 
    • Mode overlap - Calculating the overlap of an input beam to the cavity
    • Mode matching - Calculating a mode matching telescope into the cavity for some defined input beam
    • Anything else?

I have added lots of information to the help header, so check there for more details. As always, your feedback is greatly appreciated.

  8125   Wed Feb 20 23:25:50 2013 ZachSummaryElectronicsReplacement for the AD743: OPA140 and OPA827

I have found two great FET input chips that rival the storied, discontinued AD743. In some ways, they are even better. These parts are the OPA140 and the OPA827.

Below is a plot of the input-referred voltage noise of the two op amps with Rsource = 0, along with several others for comparison. The smooth traces are LISO models. The LT1128 and AD797 are BJT-input parts, so their voltage noise is naturally better. However, the performance you see here for the FET parts is the same you would expect for very large source impedances, due to their extremely low current noise by comparison. I have included the BJTs so that you can see what their performance is like in an absolute sense. I have also included a "measured" trace of the LT1128, since in practice their low-frequency noise can be quite higher than the spec (see, for example, Rana's evaluation of the Busby Box). The ADA4627 is another part I was looking into before, the LT1012 is a less-than-great FET chip, and the AD797 a less-than-great BJT.

As you can see, the OPA140 actually outperforms the AD743 at low frequencies, though it is ~2x worse at high frequencies. The OPA827 comes close to the AD743 at high frequencies, but is a bit worse at low ones. Both the OPA140 and OPA827 have the same low-frequency RMS spec, so I was hoping it would be a better all-around part, but, unfortunately, it seems not to be.

The TI chips also have a few more things on the AD743:

  • Input current noise @ 1kHz
    • AD743: 6.9 fA/rtHz
    • OPA827: 2.2 fA/rtHz
    • OPA140: 0.8 fA/rtHz (!)
  • Input bias (offset) current, typ
    • AD743: 30 pA (40 pA) --- only for Vsupply = ±5 V
    • OPA827: ±3 pA (±3 pA) --- up to ±18V
    • OPA140: ±0.5 pA (±0.5 pA) (!) --- up to ±18V
  • Supply
    • Both OPA140 and OPA827 can be fed single supplies up to 36V absolute maximum
    • The OPA140 is a rail-to-rail op amp

These characteristics make both parts exceptionally well suited for very-high source impedance applications, such as very-low-frequency AC-coupling preamplifiers or ultra-low-noise current sources.

 ULN_opamp_comparison_2_20_13.png

(Apologies---the SR785 I was using had some annoying non-stationary peaks coming in. I verified that they did not affect the broadband floor).

R.I.P., AD743

  8151   Sat Feb 23 18:01:38 2013 ZachSummaryElectronicsReplacement for the AD743: OPA140 and OPA827

Rana suggested that I measure the OPA827 and OPA140 noise with high source impedance so as to see if we could find the low-frequency current noise corner. Below is a plot of both parts with Rs = 0, 10k, and 100k.

As you can see, both parts are thermal noise limited down to 0.1 Hz for up to Rs = 100k or greater. Given that the broadband current noise level for each part is ~0.5-1 fA/rtHz, this puts an upper limit to the 1/f corner of <100 Hz. This is where the AD743 corner is, so that sounds reasonable. Perhaps I will check with even higher impedance to see if I can find it. I am not sure yet what to make of the ~10-20 kHz instability with high source impedance.

OPA140_OPA827_noise_vs_Rs.png

EDIT: The datasheets claim that they are Johnson noise limited up to 1 Mohm, but this is only for the broadband floor, I'd guess, so it doesn't really say anything about the low frequency corner.

Screen_Shot_2013-02-24_at_12.12.23_PM.png Screen_Shot_2013-02-24_at_12.12.43_PM.png

Quote:

I have found two great FET input chips that rival the storied, discontinued AD743. In some ways, they are even better. These parts are the OPA140 and the OPA827.

 

  8420   Sun Apr 7 20:49:19 2013 ZachUpdateGeneralRestarted elog

with the script, as it was down.

  8428   Tue Apr 9 01:46:40 2013 ZachUpdateGeneralRestarted elog

Again.

Quote:

with the script, as it was down.

 

  10019   Tue Jun 10 11:54:36 2014 ZachConfigurationWikiDokuWikis are still down

Not sure if someone is already on this, but the nodus DokuWikis are still down (AIC, ATF, Cryo, etc.)

I get:

DokuWiki Setup Error

The datadir ('pages') does not exist, isn't accessible or writable. You should check your config and permission settings. Or maybe you want to run the installer

  10022   Wed Jun 11 05:16:14 2014 ZachConfigurationWikiDokuWikis are back up

It looks like auth is broken on the AIC wiki (though working fine on ATF and Cryo). I did some poking around but can't see how anything we did could have broken it.

Quote:

As of this writing, the DokuWiki appears to be working.

 

  10029   Wed Jun 11 20:09:37 2014 ZachConfigurationWikiDokuWiki situation

I have been looking into the DokuWiki situation, with no great progress so far.

The problem is with authentication. When you try to access the wiki, you get: "User authentication is temporarily unavailable. If this situation persists, please inform your Wiki Admin."

 As Evan points out, this goes away if you turn off ACL (Access Control Lists), but---as he also mentions---that just means that authentication is disabled, so the wiki becomes open. All signs point to this being a problem with the authentication mechanism. We use the 'authplain' plaintext method, where the usernames and hashed passwords are stored in a plaintext file.

Evan and I have both done plenty of testing with the config settings to see if the problem goes away. Even if you restore everything to default (but enable ACL using authplain and the existing user file), you still get an error.

I went as far as installing a brand new wiki on the web server, and, surprisingly, this also exhibits the problem. Interestingly, if I install an old enough version (2012-10-13), it works fine. After this revision, they transitioned their authentication methods from "backends" to "plugins", so this is a clue. As a side note, the other wikis on nodus (ATF and Cryo) are running earlier versions of DokuWiki, so they have no problems.

As it stood, our options were:

  1. No wiki (not even read-only, since the issue prevents logging in and also prevents anonymous reading, somehow)
  2. No ACL = open wiki. Also not good.

So, I created a temporary read-only version of the wiki using the aforementioned earlier DokuWiki release. It has a soft link to the real wiki data, but I deleted the user database so no one can log in and edit (I also disabled registration). It can be found at https://nodus.ligo.caltech.edu:30889/wiki_ro/.

I also created a backup of the real wiki as wiki_bak to avoid any potential disasters.

The simplest thing to do would be to just roll the wiki back to this working version, but that doesn't sound so smart. Clearly, it was working with the plugin structure before our snafu, and somehow our fixing everything else has broken it.

Quote:

Quote:

It looks like auth is broken on the AIC wiki (though working fine on ATF and Cryo). I did some poking around but can't see how anything we did could have broken it.

I went into local.php and changed $conf['useacl'] = 1; to $conf['useacl'] = 0; and it looks like the auth issue goes away (I've changed it back). This isn't a fix (we want to use access control), but it gives us a clue as to where the problem is.

 

  11058   Mon Feb 23 15:04:10 2015 ZachUpdateGeneralElog restarted

The elog crashed while I was creating an entry to the Cryo log. I restarted it with the start-elog.csh script.

  2888   Thu May 6 17:54:44 2010 Zach Korth -- Committee Oversight (Fun Division)OmnistructureTMIMinutes from the Lab Organization Commitee meeting

Where are we going to put the tiki bar? The ice cream machine? I am disappointed in the details that appear to have been glossed over..

Quote:

Today we met and we finally come up with a lot of cool, clever, brilliant, outstanding ideas to organize the lab.

You can find them on the Wiki page created for the occasion.

http://lhocds.ligo-wa.caltech.edu:8000/40m/40m_Internals/Lab_Organization

Enjoy!

 

  7934   Wed Jan 23 20:46:46 2013 Zen MasterUpdateLockingPR-flat cavity status - locks!

Quote:

I (with help from Q)

 Two quadratures working in harmony.

yinYang.png

  6392   Fri Mar 9 11:59:38 2012 Zweizig the ELOG MavenSummaryCDSNDS2 restart

 Hi Rana,

It looks like the channe list file has a few blank lines that the channel list reader is choking on. I removed the lines and it is working now.. I have made the error message a bit more obvious (gave the file name  and line number) and allowed it to ignore empty lines so this won't cause problems with future versions (when installed). The bottom line is nds2 is now running on mafalda.
Best regards,

John   

  13434   Fri Nov 17 16:31:11 2017 aaronOmnistructureComputersAcromag wired up

Acromag Wireup Update

I finished wiring up the Acromags to replace the VME boxes on the x arm. I still need to cut down the bar and get them all tidy in the box, but I wanted to post the wiring maps I made.
I wanted to note specifically that a few of the connections were assigned to VME boxes but are no longer assigned in this Acromag setup. We should be sure that we actually do not need to use the following channels:

Channels no longer in use

  • From the VME analog output (VMIVME 4116) to the QPD Whitening board (no DCC number on the front), 3 channels are no longer in use
  • From the anti-image filter (D000186) to the ADC (VMIVME 3113A) 5 channels are no longer in use (these are the only channels from the anti-image filter, so this filter is no longer in use at all?)
  • From the universal dewhitening filter (D000183) to a binary I/O adapter (channels 1-16), 4 channels are no longer in use. These are the only channels from the dewhitening filter
  • From a second universal dewhitening filter (D000183) to another the binary I/O adapter (channels 1-16), one channel is no longer in use (this was the only channel from this dewhitening filter).
  • From the opti-lever (D010033) to the VME ADC (VMIVME 3113A), 7 channels are no longer in use (this was all of the channels from the opti lever)
  • From the SUS PD Whitening/Interface board (D000210) to a binary I/O adapter (channels 1-16), 5 channels are no longer in use. 
  • Note that none of the binary I/O adapter channels are in use.

 

  14022   Tue Jun 26 20:59:36 2018 aaronUpdateOMCprep for vent in a couple weeks

I checked out the elog from the vent in October 2016 when the OMC was removed from the path. In the vent in a couple weeks, we'd like to get the beam going through the OMC again. I wasn't really there for this last vent and don't have a great sense for how things go at the 40m, but this is how I think the procedure for this work should approximately go. The main points are that we'll need to slightly translate and rotate OM5, rotate OM6, replace one mirror that was removed last time, and add some beam dumps. Please let me know what I've got wrong or am missing.

[side note, I want to make some markup on the optics layouts that I see as pdfs elsewhere in the log and wiki, but haven't done it and didn't much want to dig around random drawing software, if there's a canonical way this is done please let me know.]

Steps to return the OMC to the IFO output:

  1. Complete non-Steve portions of the pre-vent checklist (https://wiki-40m.ligo.caltech.edu/vent/checklist)
  2. Steve needs to complete his portions of the checklist (as in https://nodus.ligo.caltech.edu:8081/40m/12557)
  3. Need to lock some things before making changes I think—but I’m not really sure about these, just going from what I can glean from the elogs around the last vent
    1. Lock the IMC at low power
    2. Align the arms to green
    3. Lock the arms
    4. Center op lev spots on QPDs
    5. Is there a separate checklist for these things? Seems this locking process happens every time there is a realignment or we start any work, which makes sense, so I expect it is standardized.
  4. Turn/add optics in the reverse order that Gautam did
    1. Check table leveling first?
    2. Rotate OM5 to send the beam to the partially transmissive mirror that goes to the OMC; currently OM5 is sent directly to OM6. OM5 also likely needs to be translated forward slightly; Gautam tried to maintain 45 deg AOI on OM5/6.
    3. A razor beam dump was also removed, which should be replaced (see attachment 1 on https://nodus.ligo.caltech.edu:8081/40m/12568)
    4. May need to rotate OM6 to extract AS beam again, since it was rotated last time
    5. Replace the mirror just prior to the window on the AP table, mentioned here in attachment 3: https://nodus.ligo.caltech.edu:8081/40m/12566
      1. There is currently a rectangular weight on the table where the mirror was, for leveling
  5. Since Gautam had initially made this change to avoid some backscattered beams and get a little extra power, we may need to add some beam dumps to kill ghosts
    1. This is also mentioned in 12566 linked above, the dumps are for back-reflection off the windows of the OMC
  6. Center beam in new path
  7. Check OMC table leveling
  8. AS beam should be round on the camera, with no evidence of clipping on any optics in the path (especially check downstream of any changes)
  14051   Wed Jul 11 15:57:00 2018 aaronUpdateOMCReviving OMC electronics
Gautam showed me the electronics racks for the OMC PZTs and DAQ. I'm in the process of chasing down what channels we need, and confirming that we'll be able to plug the old antialiasing/imaging boards into the current DAC/ADC boards. I found what I think was Rob Ward's simlink model for the omc, located at
 
/cvs/cds/caltech/cds/rward-advLigo/src/epics/simLink/omc.mdl
 
Channels in this model:
  • 27 or 29 total ADC channels are used (depending whether we keep 2 spare adc chans)
    • 4 each go to ASC_QPD1/2 (8 chans total)
    • 5 go to TRANS_PD1, TRANS_PD2, REFL_PD, TRANS_PD1_UF, TRANS_PD2_UF. These PD are used for ASC and LSC.
    • 2 go to the LSC, one each for DVMDC, DVMAC, X3DC, and X4DC
    • 12 go to the ASC_PZT
    • 2 go to the SPARE_ADC (not sure what this is)
    • I think these channels are (or were at some point) defined in memory by /cvs/cds/caltech/chans/ipc/G1.ipc
      • I found this from elog 2860; it mentions that these should eventually be migrated over to a file C1.ipc, but I don't see any OMC channels in that file or any of the 'old' C1.ipc files, so I suppose it never happened or they were removed later
    • During this vent, we won't have ASC, so
  • 10 or 14 DAC channels are used (depending whether we keep 4 spare dac chans)
    • 2 from the LSC, one for CLK_OUT and one for "LSC"
    • 8 from ASC, including P1A, P1B, P2A, P2B, P1OSC, Y1OSC, P2OSC, Y2OSC
    • I think these channels are (or were at some point) saved to frames due to /cvs/cds/caltech/chans/daq/C1OMC.ini, which I found from elog 2073
    • At some point, the 33MHz mod depth was controlled by one of the spare OMC chans, C1:OMC-SPARE_DAC_CH_15. See elog 2126. I assume this is no longer the case, since c1omc is defunct.
    • Durnig this vent, we won't have ASC and don't need to CLK_OUT the LSC, so we may just need one DAC channel

As of at least Nov 2009, the .par file for the OMC was located at /cvs/cds/gds/param/tpchn_C2 (see elog 2316)

 
Electronics inventory:
  • Kepco HV supply, "OMC-L-PZT", labels indicate it goes to 250V, needs to be tested  ("TESTED OK 2014OCT12")
  • Tip/Tilt Piezo Driver, LIGO D060287
  • HV Piezo Driver, LIGO D060283
  • QPD Whitening Board, D060214
  • LIGO D050374/D050387
  • LIGO D050368/D050373

Need to check:

  • Can the ADC/DAC adapter boards (eg D0902006) drive whatever ~10V control signal we need across ~10m of SCSI cable?
  •  
ELOG V3.1.3-