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

  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

  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.

  6022   Mon Nov 28 14:27:35 2011 JenneUpdateRF SystemEOM temp driver

Here is 5 days of trend of the EOM temp sensor and the heater driver monitor.  Unfortunately, it looks like we're regularly railing the heater.  Not so awesome. 

Attachment 1: EOM_temp_driver_3days.png
EOM_temp_driver_3days.png
  6023   Mon Nov 28 14:40:43 2011 KojiUpdateRF SystemEOM temp driver

Quote:

Here is 5 days of trend of the EOM temp sensor and the heater driver monitor.  Unfortunately, it looks like we're regularly railing the heater.  Not so awesome. 

Can you zoom the temp mon? (V= -0.1 ~ +0.1)
The crystal was too cold and I tried to heat the PSL table by the lighting. But it seemed in vain.

  6025   Mon Nov 28 15:43:36 2011 steveUpdateRF SystemEOM temp zoomed

Quote:

Quote:

Here is 5 days of trend of the EOM temp sensor and the heater driver monitor.  Unfortunately, it looks like we're regularly railing the heater.  Not so awesome. 

Can you zoom the temp mon? (V= -0.1 ~ +0.1)
The crystal was too cold and I tried to heat the PSL table by the lighting. But it seemed in vain.

 It is not working

Attachment 1: eomtempmon.png
eomtempmon.png
  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.

 

  6036   Tue Nov 29 15:25:29 2011 steveUpdateRF SystemEOM temp stabilization performance

 It is not obvious what is working.

 

Attachment 1: 2days.png
2days.png
  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

  6044   Tue Nov 29 22:10:18 2011 kiwamuUpdateRF SystemRFAM fluctuation reduced

Quote from #6035

I left the EOM stabilization running overnight, so we can finally see how the EOM temperature stabilization does over long periods of 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. 

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

However the absolute value of the RFAMs stayed at relatively high value.

I guess we should be able to set the right temperature setpoint such that the absolute value of the RFAM is smaller.

Here is the calibrated RFAM data (for 5 hours around the time when Zach activated the temperature control last night):

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

  6050   Wed Nov 30 03:01:55 2011 kiwamuUpdateRF SystemRFAM fluctuation reduced

Okay I have turned ON the temperature control at 2:40 AM and will leave it ON for a while.

Quote from #6047

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

 

  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.

  6054   Wed Nov 30 14:12:53 2011 JenneUpdateRF SystemNew EOM mount almost ready

The new EOM adapter plate and riser just got back from the shop.  I just had Mike do the milling, and I'll drill and tap them tomorrow after the TAC.  Then we can remount the EOM to see if stiffening the mount helps at all.

  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.
  6056   Thu Dec 1 01:24:56 2011 JenneUpdateRF SystemEOM temp stabilization at PSL lab

[Frank, Jenne]

Activities in a far, far away land called PSL lab...

EOM_Temp_stab_30Nov2011.png

We are looking at the RFAM from the detuned ACAV refl pd in the red trace.  Red trace is the demodulated RFAM output.  RCAV was locked, so on a ~min time scale the freq drift follows, so we stay detuned. 

Heater and temp sensor are taped to EOM, no foam box.

Around when the red trace starts, we turn on the heater to stabilize the temp.  After a while we reach the set point (no longer railing the heater), and start seeing temp stabilization.  The RFAM fluctuations clearly go down.  Neato. 

No calibrations, no RIN, no nothing.  Get over it.

Green trace is the DC level of a different PD, which should also be sensitive to RFAM.

This is using a fancy-pants temp controller chip that Frank found.  It works, so that's handy.

  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. 

  6073   Mon Dec 5 19:38:38 2011 JenneUpdateRF SystemEOM mount getting closer....

I have drilled all the holes necessary, and have tapped all but 4 of the holes for the new EOM mount.  The adapter plate is finished and ready to go (including a 10-min iso sonic bath).  The riser that goes between the table and the 9082 mount is drilled but not yet tapped.

  6077   Tue Dec 6 21:37:08 2011 JenneUpdateRF SystemNew EOM mount in place

EOM is remounted on the fancy-pants new mount that I crafted.  EOM is also aligned.  2 green mirrors (the first ones to see the beams coming onto the PSL table from the arm transmissions) had to be moved so I could fit the mount in, since the new mount is bigger than the old one.  I put them back, and approximately realigned them, but didn't do any fine alignment.  This must be done before looking at beatnotes again.

After playing with the EOM, the MC was flashing on higher order modes.  The PSL beam has been realigned to make the MC lock on TEM00, and Suresh helped me center on the WFS and MC2T.

Things look okay for now.  Next step:  Kiwamu needs to find his happy mode cleaner place, and we'll realign the PSL beam to the MC.  The PSL-MC axes were mismatched pretty badly according to Suresh anyway, so this had to be done no matter what.

  6079   Wed Dec 7 00:48:58 2011 kiwamuUpdateRF SystemRealigned incindent pointing to MC
Actually it was already in a good place.
I just realigned the zig-zag mirrors on the PLS table to bring the entire beam axis a little bit upward.
The WFS servo still seems fine. The input pzt mirrors are still within their range.

Quote from #6077

Next step:  Kiwamu needs to find his happy mode cleaner place, and we'll realign the PSL beam to the MC.  The PSL-MC axes were mismatched pretty badly according to Suresh anyway, so this had to be done no matter what.

  6082   Wed Dec 7 18:47:36 2011 JenneUpdateRF SystemRAM Mon is now being demodulated

There were 2 open outputs on the splitter in the RAMmon (formerly known as Stochmon) box underneath the BS oplev table.  The input to the splitter comes from the Thorlabs PD that we're using as our RAM monitoring PD.  2 of the outputs go to the RMS detection of 11 and 55 MHz.  Now the other 2 (previously terminated) outputs go over to the LSC rack via SMA cable.  The signal on both channels is ~200mV pk-pk, so -10dBm.  One is plugged into the AS11 demod board (which didn't have a PD input yet), and the other goes to POP55's demod board, so POP55 is not what you think it is for now.

Koji is working on checking out the Rich box, which has 4 demodulators, which we will use eventually.  Right now we're just using the already-plugged-in demod boards so we can start looking at some trends of RAM.  We're going to need to find some channels when we're ready for the switchover.

Zach is nearing completion of the mini-update to the temp sensing system.  Once we have the new more sensitive temp sensor in place, we can have a look-see at the similarities between EOM temperature and RAM levels.

  6086   Thu Dec 8 00:45:13 2011 KojiUpdateRF System4ch demod is ready

I have tested the left 2ch of 4ch demod board.

The left most is for 11MHz, and the next one is for the 55MHz.

  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

  6090   Thu Dec 8 16:54:05 2011 JenneUpdateRF SystemInstallation of new demod box

So far:

* New demod box has been placed in the LSC rack.

* An extra set of +\- 24V has been prepared at the terminal block where all the Crates get their power on the LSC rack.  The grounds were all connected up, but the hot wires weren't.  So there were extra spots available, but none that were pre-wired with my voltages.

     * To do this I turned off all the power supplies in the short rack, since I decided to be a live chicken rather than a dead duck.  After hooking up the new terminal block slots, I turned on the power supplies.

 * Make a power cable to go from the terminal block to the box

Still to do:

 * Connect the spare 55MHz LO and the POP (or POX or POY) unused 11MHz LO to the back of the box

 * Move the PD inputs to the new demod box rather than the borrowed AS11 and POP55 boards

 * Plug the I & Q outs for each freq into some spare ADC channels - must first make sure we have 4 open channels.

 * See if it works.

  6092   Thu Dec 8 22:44:55 2011 KojiUpdateRF System4ch demod test result

1) Linearity Test

LO input level was +10dBm. The LO freq was 11MHz and 55MHz for CH1 and CH2 respectively.
The IF frequency was fixed at 10kHz.

The amplitude of the RF input was swept from -50dBm to +15dBm.
Basically I and Q output of CH1 and CH2 was quite linear in this amplitude range.

2) Freqency Response

RF input was fixed at -20dBm and the IF frequency was swept from 1kHz to 1MHz.

The response was flat upto 100kHz, and have sensitivity upto 300kHz.

3) Output noise

Noise floor of the output is ~20nV/rtHz. All of the channels behave in the same way.
1/f start from 100Hz.

Attachment 1: RF_DEMOD_TEST_111208.pdf
RF_DEMOD_TEST_111208.pdf RF_DEMOD_TEST_111208.pdf RF_DEMOD_TEST_111208.pdf
  6097   Fri Dec 9 17:08:41 2011 JenneUpdateRF SystemLots of current used in Rich's demod box

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.

  6099   Fri Dec 9 17:44:45 2011 KojiUpdateRF SystemLots of current used in Rich's demod box

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.

 

  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.

 

 

  6104   Mon Dec 12 11:16:02 2011 JenneUpdateRF SystemFoam house on EOM

Foam house installed on EOM a few min ago.  We'll leave it until ~tomorrow, then try out the heater loop.

  6109   Mon Dec 12 16:57:38 2011 JenneUpdateRF SystemRAMmon, 4 day trend

EOM was aligned to minimize the 11 and 55 MHz peaks in the RAMmon PD the other day (elog 6089), and was left with just the temperature sensor attached, no heater, no foam box.

Here is a 4 day trend:

EOM_tempSense_noFoam_noHeater_RAMmon_4days.png

I don't have a whole lot to say about this, other than there's a lot of stuff going on.  The craziness at the end is me realigning the PMC and MC since, as you can see, MC trans was way down.  The foam box was put on earlier today (elog 6104), so we'll see how that changes things over night.

  6111   Tue Dec 13 11:34:32 2011 JenneUpdateRF SystemRAMmon, 5 day trend

Now we've got another day of data, with the foam box on for the last 24hrs.

First plot is a 5 day trend so you can see that the RAM has gotten a little bit smaller, as has the temperature drift, but not by a whole lot.

EOM_tempSense_RAMmon_5days_last_day_withFoam_noHeater.png

Second plot is the last 19 hours (so excluding much of the time while I was realigning beams on the PSL table yesterday), to zoom in on just the time when the foam box was installed.

EOM_tempSense_withFoam_noHeater_RAMmon_1day.png

After lunch Zach and I are going to engage the heater to temperature stabilize the system, to see how that affects things.

In other news, the MC looks like it was fine for a good long time, and ~3 hours ago it went bad.  The mode that's flashing is really bad in both pitch and yaw.  I don't know what happened, but something is not so awesome. Edit: Steve said that he opened the PSL table at some point this morning to look around but not touch, and also it's Janitor Day, and Kevin comes in around 8ish. That doesn't mean I know the actual cause, but those are the only things that happened in the IFO room this morning that anyone is aware of.

  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

  6119   Wed Dec 14 14:30:43 2011 JenneUpdateRF SystemLO for new demod box

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

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

 

 

  6123   Wed Dec 14 19:59:12 2011 JenneUpdateRF SystemLO for new demod box

Quote:

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

 

 

 Yeah, I looked and saw that it's a semiconductor mixer, so it doesn't have to be as perfect. 

Everything is plugged in now to the new demod board.  More details soonly...

The I & Q outs are plugged into whitening filter #3, channels 5-8.  11MHz I = chan 5, 11MHz Q = chan 6, 55MHz I = chan 7, 55MHz Q = chan 8.  These channels are probably already recorded, but I haven't checked yet.  Hopefully I'll have time tonight after I pack for my trip.  But Zach, can you look into it tomorrow just to check??  Backup plan is to just go back to using the AS11 and POP55 boards and channels if the new board isn't doing what it's supposed to.

I disconnected the 3rd and 4th channels of the demod box since they were drawing unnecessary current, and making the box hot.  Now the box is just warmish.

  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.

  6390   Fri Mar 9 10:44:57 2012 steveUpdateRF SystemOSA

Optical spectrum analyzers like the Attachment made by Coherent , Meles Griot- CVI and Spectral Product are all discontinued.

The 40m have Coherent models C240 analyzer with controller C251 Their Finesse measured in 2004: sn205408  F302,  sn205409  F396,

Jenne borrowed Jan's Meles Griot model 13SAE006, Peter King has the same model. FSR 300 MHZ, finnees 200 minimum

Attachment 1: OSA.pdf
OSA.pdf
  6402   Mon Mar 12 22:14:56 2012 SureshUpdateRF SystemCalibration of Demod Board Efficiency.

I have completed the calibration of the demod board efficiencies.  Here is the schematic of the set-up.

 Calibration_Schematic.png

The data is given below and the data-file is attached in several different formats.

 Demod_calib.png

 

Attachment 3: Demod_calib.txt
								
	Measurements			 After corrections			Efficiency= out/in	
Demod Board	mV_ampl	mV_pk-pk	mV_pk-pk	mV_ampl	mV_ampl	mV_ampl	Vout/Vin	Vout/Vin
	PD in	Q out	I out	PD in	Q out	I out	Q out	I out
REFL33	10.6	10.0	10.0	9.4	5.0	5.0	0.53	0.53
AS11	24.0	10.0	11.0	21.3	5.0	5.5	0.23	0.26
REFL11	22.5	240.0	255.0	20.0	120.0	127.5	6.00	6.38
POX11	24.0	9.2	8.5	21.3	4.6	4.3	0.22	0.20
POY11	22.4	10.5	9.0	19.9	5.3	4.5	0.26	0.23
AS55	17.6	268.0	268.0	15.6	134.0	134.0	8.57	8.57
REFL55	19.7	15.8	15.5	17.5	7.9	7.8	0.45	0.44
POP55	18.8	278.0	274.0	16.7	139.0	137.0	8.32	8.20
REFL165	21.2	16.0	16.4	18.8	8.0	8.2	0.42	0.44
POY110	23.4	14.7	14.4	20.8	7.4	7.2	0.35	0.35
POY22	17.5	11.9	9.3	15.6	6.0	4.6	0.38	0.30
Attachment 4: Demod_calib.xlsx
  7353   Thu Sep 6 18:49:30 2012 JenneUpdateRF SystemAS 55 may be broken

I was going to lock MICH, but I don't see anything on dataviewer for either AS55Q or ASDC.  I went out onto the table, and there is beam on the diode, but no mV out on a voltmeter connected to the DC monitor point.  I shine a flashlight, and still I see 0.0mV.  So, something is up with AS55, but since the michelson is aligned right now, I'm not going to mess with the PD.  I won't lock MICH, I'll just move on.  Koji is taking a look at the diode, but if he doesn't get it figured out tonight, we can take a closer look after we pump down.

  7355   Thu Sep 6 19:36:19 2012 JenneUpdateRF SystemAS 55 is fine

Quote:

I was going to lock MICH, but I don't see anything on dataviewer for either AS55Q or ASDC.  I went out onto the table, and there is beam on the diode, but no mV out on a voltmeter connected to the DC monitor point.  I shine a flashlight, and still I see 0.0mV.  So, something is up with AS55, but since the michelson is aligned right now, I'm not going to mess with the PD.  I won't lock MICH, I'll just move on.  Koji is taking a look at the diode, but if he doesn't get it figured out tonight, we can take a closer look after we pump down.

 Never mind.  I was using an LED flashlight, which doesn't emit light that the PD is sensitive to.  A regular flashlight gives plenty of signal on the DC out. 

Using an SR560 with 30Hz low pass and gain of 100, it was pretty easy to align the light on the PD. 

Koji calculates in his head that there is about 6 microwatts of light incident on the PD, which is not a lot of light. Our SNR may be kind of lame for locking right now.

  7974   Thu Jan 31 14:46:05 2013 JenneUpdateRF SystemPhotodiode transimpedance

Quote:

Today I collected the data for shot noise intercept current for MC REFL PD. I didn't get many data points at higher DC voltage of the photodiode, cause the incandescent bulbs get burnt at that level; two bulbs I have burnt today. I will process the data and report.

 This work was done in-situ, so no optics on the AS table were moved.  The PSL shutter was blocked since the IR beam was not necessary, and would scatter off the bulb Riju put in front of the PD. 

  7976   Thu Jan 31 15:34:22 2013 RijuUpdateRF SystemPhotodiode transimpedance

Quote:

Quote:

Today I collected the data for shot noise intercept current for MC REFL PD. I didn't get many data points at higher DC voltage of the photodiode, cause the incandescent bulbs get burnt at that level; two bulbs I have burnt today. I will process the data and report.

 This work was done in-situ, so no optics on the AS table were moved.  The PSL shutter was blocked since the IR beam was not necessary, and would scatter off the bulb Riju put in front of the PD. 

 Thanks Jenne.

  8038   Fri Feb 8 17:15:56 2013 JenneUpdateRF SystemMC REFL Photodiode transimpedance

This measurement was done already about a week ago, in elog 7984.  Can you please describe why the numbers for the last measurement were not believable, and what was done differently this time?

ELOG V3.1.3-