40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 184 of 341  Not logged in ELOG logo
ID Date Authorup Type Category Subject
  5807   Fri Nov 4 13:04:50 2011 ZachUpdateGreen LockingPassive summing box modifications

I spent some time the other day trying to diagnose the problem with the Y Arm universal PDH box (S/N 17), which Katrin has been unable to use for locking the green beam. As far as I can tell, there is nothing wrong with the box itself (though the weird TF behavior that Katrin noticed was not initially reproducible, so its cause may still be there).

I did notice that I was unable to generate a PDH error signal using the universal box. In this configuration, a summing circuit is needed to add the PZT modulation signal (fmod = 178875 Hz) in along with the feedback signal. To do this, Katrin was using a slightly different version of the passive summing box that Kiwamu built for the X Arm. I read this entry to understand how it is supposed to work and noticed that the "expected transfer functions" were not what the circuit actually does. I have talked to Kiwamu about it and he found that he posted the wrong TFs (he has the right ones on his computer). As you can see from the plot below, there is extra low passing that severely attenuates the modulation path to the PZT. In addition, there is a phase shift of ~-60 degrees, which is bad.

To combat this, I propose we simply change the resistor in the modulation path from 1M to 10k. This leaves the feedback path TF unchanged, and changes the mod path into a sort of bandpass filter for the modulation frequency. The fact that the phase is near zero at fmod means we don't have to come up with some way to phase shift the signal for demodulation. The attenuation level of ~-36 dB is also convenient: The ZAD-8 mixer wants 7 dBm, so, 10 dBm (FG) - 3 dB (splitter) - 36 dB (sumbox) = -25 dBm ~ 12 mV. This is roughly the desired PZT voltage level.

sum_circuit_new.png sumbox_TFs.png

  5808   Fri Nov 4 13:13:25 2011 ZachUpdateGreen LockingPDH box #17 modified, too

I also modified the Y-Arm PDH box itself slightly. Previously, there was a flying 10k resistor from the SWEEP input to TP2. I don't see the point of this, so I moved it from TP2 across R19 (to the same point where it is on the gyro PDH boxes) to allow for excitation signals to be injected with the loop closed (i.e., with the SWEEP switch off). This is useful for OLTF measurements.

  5822   Sat Nov 5 21:19:08 2011 ZachUpdateSUSDr. SUS paths updated--question of human oversight remains

Ok, here's the deal:

  • For the time being, I have written a "doirun" bit into runDrSUS (i.e. it runs if doirun is 1 and doesn't if it's 0). This is a bad way of doing this, so in the end I think we should put a switch on the IFO MEDM and have the script read the value when the cron job is run. If you want it to be an opt-in rather than a toggle, we can have the script write it back to 0 every time. I don't know how to do this yet because I am an MEDM n00b, but I will do it soon.
  • Since we have decided to keep a human in the loop on the writing to the frontend, I have kept the elog results push.
  • I have also edited diagAllSUS.m so that it archives all computed matrices (hierarchy: .../scripts/SUS/peakFit/inMats/(gps_time_of_kick)/inMat(optic_name).mat). There is a 'writematrices' bit in the M-file, currently set to 0.
  • I have written the script 'writeAllInMats' and the accompanying M-file 'writeAllInMats.m'. This allows the user to write whichever set of input matrices he or she desires (syntax: writeAllInMats (gps_time_of_kick)). If no argument is given, then it reads the most recent kick time from 'kickAll.time' and writes the corresponding matrices.

So, here is an example of how this works:

  1. Someone decides to do a diagonalization on a particular weekend, (eventually) clicking a switch in MEDM
  2. Cron runs runDrSUS at 8am that Sunday. This:
    1. Kicks all the optics, lets them swing for 5 hours, then reengages the watchdogs. The kick time is saved in kickAll.time, and an alert is posted to the elog
    2. Runs diagAllSUS, which computes and saves all matrix data. A report of the results is posted to the elog.
  3. On Monday morning---or whenever---someone looks at the entry and decides whether or not to write the files
    1. If the results are good, he or she runs writeAllInMats and the latest matrices are written
    2. If the results are bad, he or she does nothing. The matrices are still archived and can be written at any time in the future.

The code is set to run tomorrow morning. Everything but the writing will be done.

Quote:

My inclination is to not do the writing of the matrices automatically nor to do the weekly kicks. Its nice to have long locks of the MC, etc.

I suggest just making the kick on Sundays when someone intentionally asks for it (e.g. by pressing a button on Friday). The free-swinging ringdown ought to be a opt-in kind of feature, not opt-out.

 

  5824   Sun Nov 6 16:58:25 2011 ZachUpdateSUSDr. SUS failed--NDS2 problems again

 Dr. SUS failed while trying to get the sensor data. Specifically, it couldn't get ETMY data. This is odd, because in my tribulations last week I ended up having to add the ETMY_SENSOR channels manually into the NDS2 channel files. After doing this, I was able to get ETMY data just fine (though I admitted that we would have problems again as soon as we wanted to update the channel files). I even ran the diagAllSUS code in a sandbox and it pulled data---and generated input matrices---just fine.

The error persists even if I try to get the data manually:

 

>> d = NDS2_GetData({'C1:SUS-ETMY_SENSOR_UL'},t0,10,'mafalda.martian:31200');

Connecting.... authenticate done

Warning: daq_recv_next failed

 

??? Error using ==> NDS2_GetData

Fatal Error getting channel data.

I think Jamie is still waiting for J.Z.'s help with this, but it is probably pointless to keep trying to run this code before NDS2 is working again. Another option is to just use NDS, but I think certain people are opposed to this. 

 

 

  5829   Mon Nov 7 12:51:44 2011 ZachUpdateelogRestarted elog

I've noticed that it always takes running the script twice for it to actually work. I think there's something wrong with how it's doing it. I'll mess with it sometime the elog isn't getting much use.

Quote:

Elog restart script killed the elog, but didn't restart it.  Restarted by hand.

 

  5868   Fri Nov 11 00:18:53 2011 ZachUpdateElectronicsPrecision temperature controller

I have made a first draft of the precision temperature controller circuit, which could find use at the 40m for stabilizing EOM RFAM as well as in the Bridge labs. Please read the entry on the ATF Lab elog and give me your feedback.

  5893   Tue Nov 15 09:51:04 2011 ZachUpdateGreen LockingY end PDH lock : UGF at 17 kHz

Also the servo shape formed by Newfocus LB1005 looks too simple : we should have a more sophisticated servo filter (i.e. PDH box!!).

 As promised, I will get on this this week.

  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.

 

Quote:

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.

pdh17_tf_vs_liso_11_17_11.png

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

Quote:

 

 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

Quote:

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 192.168.113.108. (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 192.168.113.226---not 131.215.113.226).

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 192.168.113.108 1234
Trying 192.168.113.108...
Connected to 192.168.113.108.
Escape character is '^]'.
TEC:OUT on
TEC:OUT
TEC:OUT?
++read eoi
1
 
2. Measuring the current temperature
 
TEC:T?
++read eoi
32.9837
 
3. Reading and then changing the set temperature
 
TEC:SET:T?
++read eoi
34.0000
TEC:T 35.0
TEC:SET:T?
++read eoi
35.0000
 
4. Figuring out that the temperature is unstable and then turning off the TEC (this is important)
 
TEC:T?
++read eoi
36.2501
TEC:OUT off
TEC:OUT?
++read eoi
0
 
(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:

error_sig_m_11_18_11.png

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:

refres1.pngrefres2.pngproto_temp_ctrl.png

schematic.png

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

Quote:

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

Yarm_ALS_2011Nov19_marked.png

  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.

EOM_temp.png

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

Screen_shot_2011-11-29_at_1.41.03_PM.png

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

Quote:

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

Screen_shot_2011-11-29_at_7.03.36_PM.png

  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?

ELOG V3.1.3-