40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 182 of 339  Not logged in ELOG logo
ID Date Authorup Type Category Subject
  3466   Tue Aug 24 22:26:16 2010 ZachUpdateelogrestarted

took two again


 Restarted the elog using the script. I had to do it twice for it to work. This is not the first time this has happened---does anyone know why this might be?


  3613   Mon Sep 27 21:57:59 2010 ZachUpdateelogelog restarted

 took two runs of the script as usual

  3989   Mon Nov 29 17:45:28 2010 ZachUpdateelogrestarted elog

 The elog was down so I restarted it. The instructions on the wiki do not work as the process has some complicated name (i.e. it is not just 'elogd'). I used kill and the pid number.

I will get around to updating the restart script to work with 2.8.0.

  3993   Tue Nov 30 11:44:36 2010 ZachUpdateelogelog restarted -- SCRIPT adapted for 2.8.0

 I have created an updated version of the "start-elog-nodus" script and put it in .../elog/elog-2.8.0. It seems to work fine.

  3998   Tue Nov 30 14:21:21 2010 ZachUpdateelogScript unnecessary
I didn't realize that the script in .../elog was configured to start 2.8.0 already. I will revert the instructions on the wiki to point to that 
  4001   Tue Nov 30 19:35:09 2010 ZachUpdateelogrestarted again

 Restarted the elog again, this time using .../elog/start-elog.csh, which Joe pointed out works just fine. I have amended the wiki instructions to point to this script, instead.

  4052   Tue Dec 14 09:26:17 2010 ZachUpdateelogrestarted

 Restarted the elog with the script

  4114   Wed Jan 5 21:19:29 2011 ZachUpdateelogrestarted

 Restarted the elog with the script

  4332   Mon Feb 21 11:05:51 2011 ZachUpdateelogrestarted

 I restarted the elog using the script.

  4334   Mon Feb 21 23:00:06 2011 ZachSummaryelogrestarted


  4378   Fri Mar 4 13:25:04 2011 ZachUpdateelogrestarted

with script

  4556   Fri Apr 22 02:10:53 2011 ZachUpdateelogrestarted

Restarted the elog with the script.

  4571   Tue Apr 26 22:56:35 2011 ZachUpdateelogrestarted

 with script

  5348   Tue Sep 6 21:00:48 2011 ZachUpdateelogelog restarted

I restarted the elog with the script as it was not up when I tried to make a post. It was again unresponsive when I went to submit, but this time the script couldn't restart it. The log said it couldn't bind to 8080, which usually happens if the daemon is still running. I pkilled it, then reran the script, and it appears to be working.

  5666   Fri Oct 14 16:20:11 2011 ZachUpdateSUSC1:SUS-ETMX_SPDMon fixed

I offered to help Kiwamu with some of the 40m work. The first task was to figure out why the ETMX side OSEM monitor was so low, since we know that the depth is about right. It was showing ~0.13 V to the others' ~0.7 V.

TL,WR: There was a wire disconnected from the breakout panel on the side of the rack

I started by pulling the board out and checking to make sure that it was working properly. I injected a sine wave to the SIDE IN and found that it showed up in the signal coming out of the back (into the crate) just fine (see below). One strange thing I noticed while testing the board is that both inputs for each used channel of the MAX333 switches on the board are shorted to their respective outputs. That is, the switches seem to be open to BOTH 0 and 1 logic states. This seems counterintuitive, but perhaps there's something about how these work that I don't know.



Then I went about tracing the signal from the back of the crate to the breakout panel on the side of the rack. I opened it up, verified that the ribbon cable was transmitting correctly, and as I went to plug it back in I noticed that one of the wires---the correct one---had come completely undone.


The screw clamp appeared to be a bit finicky, as I had to loosen and tighten it a few times before it finally seemed to grab hold of the wire. It probably just wasn't tight in the first place and the wire was pulled out. Anyway, things are working now:


  5711   Thu Oct 20 11:59:21 2011 ZachUpdateComputer Scripts / Programsmodified "dataviewer" on nodus

The "dataviewer" script was still setting the server to fb40m on nodus. I modified it to fb, so that this is the default when you enter "dataviewer" or "dv".

  5765   Sun Oct 30 23:01:51 2011 ZachUpdateSUSdiagAllSUS -- automated input matrix generator

I finally got around to wrapping up the SUS input matrix diagonalizer. The files I have added to ...scripts/SUS/peakFit are:

  • kickAll: Restores all SUS angle biases using /cvs/cds/rtcds/caltech/c1/medm/c1ifo/cmd/C1IFO_OPTICrestore.cmd XXXX &, then runs 'freeswing all'. Finally, writes an elog entry with the time when the optics were kicked and saves the gps time to 'kickAll.time'.
  • diagAllSUS.m: An M-file that calls all the other individual M-files needed for the matrix generation. What it does:
    • Reads kick time from kickAll.time
    • Runs getSensors.m to get time series from all optics' sensors
    • Runs makeSUSSpectra.m to generate spectra from time series
    • Runs findPeaks.m to fit spectra for peak frequencies
    • Loops through all optics and runs, in sequence:
      • inmat = findMatrix(XXXX) to generate the matrix for each optic
      • writeSUSinmat(XXXX,inmat) to write that matrix to the frontend
  • diagAllSUS: A wrapper for diagAllSUS.m. It also writes an elog entry and attaches the pre and post spectra demonstrating the diagonalization. The entry following this one is an example.

The following lines should eventually be added to the controls@nodus crontab:

0 8 * * 0 /cvs/cds/rtcds/caltech/c1/scripts/SUS/peakFit/kickAll

0 18 * * 0 /cvs/cds/rtcds/caltech/c1/scripts/SUS/peakFit/diagAllSUS

(i.e., do the kick at 8am on Sundays and run the diagonalization 10 hrs later at 6pm). They can be done on a different machine but then my elog commands will need to be modified.

Before we add them, we should check that they do, in fact, work. We can do this sometime while I'm at the 40m this week.

  5770   Mon Oct 31 14:06:16 2011 ZachUpdateSUSSUS input matrix diagonalizer added to crontab

I actually tried to do this last night, but I was getting a terminal error from nodus. Jamie told me to just manually redefine the TERM variable and it would work. So, I have added kickAll and diagAllSUS to controls@nodus's crontab:


nodus:~>crontab -l

0 5 * * * /opt/rtcds/caltech/c1/scripts/backup/rsync.backup

0 7 * * * /opt/rtcds/caltech/c1/scripts/backup/check_backup.sh 

0 17 * * 0 /cvs/cds/caltech/users/jenne/LIGOX/LIGOX_Pizza_Reminders.sh

0 8 * * 0 /cvs/cds/rtcds/caltech/c1/scripts/SUS/peakFit/kickAll

0 18 * * 0 /cvs/cds/rtcds/caltech/c1/scripts/SUS/peakFit/diagAllSUS

Again, their functionality should be checked before this is allowed to run on Sunday!


  5775   Tue Nov 1 13:46:03 2011 ZachUpdateSUSSUS input matrix diagonalizer REMOVED from crontab

It turns out that nodus doesn't know how to NDS2, so I can't run diagAllSUS as a cron job on nodus. To further complicate things, no other machines can run the elog utility, so I am going to have to do something shifty...

  5779   Tue Nov 1 19:26:38 2011 ZachUpdateSUS"Dr. SUS" progress

EDIT: Ran Jamie's NDS2 reset method and it's still not serving up MC data.

I am debugging the SUS input matrix diagonalization code (which I have affectionately termed "Dr. SUS") offline by running everything except the actual writing of the matrices (%writeSUSinmat()) in a sandbox directory. Some notes:

  • nodus doesn't know NDS2, but this isn't a problem given Kiwamu's reply, since we don't want to push results to the elog. I will still have the script push "optics kicked---don't touch" alerts to the elog, but I realized this can be done easily from a remote computer via in-script SSH commands. My next choice was pianosa, but even though she knows NDS2, she spits out MEX errors when I try to get data. Third stop was allegra, and she plays nice 
  • NDS2 is unable to read the MC mirror sensor data. Data from all other optics are retrieved without a problem. I verified that raw data was being written by plotting playback data in dataviewer, and I tried various times and the problem persisted. I suspect the problem is on the NDS2 server side:

The most recent entry in .../users/jzweizig/nds2-mafalda/channel_history shows nothing for MC1 2 or 3


mafalda:channel_history>more C-R-999986048-178368.cls | grep SENSOR
C1:SUS-BS_SENSOR_LL raw 0 real_4 2048 C-R
C1:SUS-BS_SENSOR_LR raw 0 real_4 2048 C-R
C1:SUS-BS_SENSOR_SIDE raw 0 real_4 2048 C-R
C1:SUS-BS_SENSOR_UL raw 0 real_4 2048 C-R
C1:SUS-BS_SENSOR_UR raw 0 real_4 2048 C-R
C1:SUS-ETMX_SENSOR_LL raw 0 real_4 2048 C-R
C1:SUS-ETMX_SENSOR_LR raw 0 real_4 2048 C-R
C1:SUS-ETMX_SENSOR_SIDE raw 0 real_4 2048 C-R
C1:SUS-ETMX_SENSOR_UL raw 0 real_4 2048 C-R
C1:SUS-ETMX_SENSOR_UR raw 0 real_4 2048 C-R
C1:SUS-ETMY_SENSOR_LL raw 0 real_4 2048 C-R
C1:SUS-ETMY_SENSOR_LR raw 0 real_4 2048 C-R
C1:SUS-ETMY_SENSOR_SIDE raw 0 real_4 2048 C-R
C1:SUS-ETMY_SENSOR_UL raw 0 real_4 2048 C-R
C1:SUS-ETMY_SENSOR_UR raw 0 real_4 2048 C-R
C1:SUS-ITMX_SENSOR_LL raw 0 real_4 2048 C-R
C1:SUS-ITMX_SENSOR_LR raw 0 real_4 2048 C-R
C1:SUS-ITMX_SENSOR_SIDE raw 0 real_4 2048 C-R
C1:SUS-ITMX_SENSOR_UL raw 0 real_4 2048 C-R
C1:SUS-ITMX_SENSOR_UR raw 0 real_4 2048 C-R
C1:SUS-ITMY_SENSOR_LL raw 0 real_4 2048 C-R
C1:SUS-ITMY_SENSOR_LR raw 0 real_4 2048 C-R
C1:SUS-ITMY_SENSOR_SIDE raw 0 real_4 2048 C-R
C1:SUS-ITMY_SENSOR_UL raw 0 real_4 2048 C-R
C1:SUS-ITMY_SENSOR_UR raw 0 real_4 2048 C-R
C1:SUS-PRM_SENSOR_LL raw 0 real_4 2048 C-R
C1:SUS-PRM_SENSOR_LR raw 0 real_4 2048 C-R
C1:SUS-PRM_SENSOR_SIDE raw 0 real_4 2048 C-R
C1:SUS-PRM_SENSOR_UL raw 0 real_4 2048 C-R
C1:SUS-PRM_SENSOR_UR raw 0 real_4 2048 C-R
C1:SUS-SRM_SENSOR_LL raw 0 real_4 2048 C-R
C1:SUS-SRM_SENSOR_LR raw 0 real_4 2048 C-R
C1:SUS-SRM_SENSOR_SIDE raw 0 real_4 2048 C-R
C1:SUS-SRM_SENSOR_UL raw 0 real_4 2048 C-R
C1:SUS-SRM_SENSOR_UR raw 0 real_4 2048 C-R


  5780   Tue Nov 1 23:13:28 2011 ZachUpdateComputersNDS2 channel files

I did some messing around with the NDS2 config and channel files and things seem to be working as expected... for now. SENSOR channel data can be acquired for all sensors on all hanging optics.

What I did:

  • NDS2 gets its channel lists from .../users/jzweizig/nds2-mafalda/nds2.conf, which is called in the start-nds2 script. Within this, there are channel.file lines that specify which channels are available for raw and trend data. The four files that were listed were:
    • C-R-raw-channel_list.txt
    • C-M-ChanList.txt
    • C-T-ChanLIst.txt
    • C-R-online-channel_list.txt (this one was listed after a hashed line, which was suspicous---see below)
  • I noticed that a grep for SENSOR only returned lines for non-MC mirrors in both "R" files
  • I also noticed that calling NDS2_GetChannels('mafalda.martian:31200') did not return any non-suffixed (i.e., raw) channel names for MCx_SENSOR channels, while non-MC SENSOR channels each had two non-suffixed listings. I thought this was strange.
  • I manually added the line "C1:SUS-MC1_SENSOR_UL 0 real_4 2048 C-R" to one of the "R" channel files, then restarted the NDS2 server, and that channel was still not served. I figured that the second "R" channel file might have been left in the config file as a mistake, so I commented it out, restarted the NDS2 server, and was able to get MC1_SENSOR_UL data. I have left the comment-out there, with a signed EDIT.
  • Wary of (and too lazy to) manually add lines for all 5 sensors for each MC mirror, I decided to try generating a channel file using the most recent .gwf file in the frames, as indicated in Joe and John's elog post. To do this, while in .../nds2-mafalda/, I ran:
    • /cvs/cds/caltech/users/jzweizig/nds2-server/bin/buildChannelList /frames/full/10042/C-R-1004246528-16.gwf > C-R-raw-channel_list.txt
  • A grep for SENSOR in the new C-R-raw-channel_list.txt now returned lines for all MC mirror sensors... BUT NOT FOR ETMY(?!). I tried some slightly older .gwf files (all from today), but the ETMY files never showed up. I had no choice but to enter them manually. Another odd thing is that the channel file generated this way seems to be fairly jumbled up, in the sense that there is no clear top-town order (e.g. SUS-BS_blah then SUS-ETMX_blah). Instead, some SUS-BS channels are here, some are after SUS-ETMX or SUS-PRM channels, etc. Look at the file to know what I mean.
  • The original raw channel file is there as C-R-raw-channel_list.txt.bak.1004247481.

In any case, as I said, everything appears to be working now, but as soon as we try to generate a new channel file using the prescribed means, there will inevitably be channels omitted. Someone who knows more than me should get to the bottom of this and wiki a strict, detailed procedure for how this is to be done.

  5781   Wed Nov 2 01:53:08 2011 ZachUpdateSUS"Dr. SUS" progress

Now that NDS2 is working, I was able to run all parts of diagAllSUS (except for the matrix writing) without errors. Barring issues with standard commands (freeswing, turnOnWatchDogs.csh, caput, etc.), Dr. SUS should be ready to go.

As requested, I have suppressed the generation of an elog post containing the results of the diagonalization.

Dr. SUS will run on allegra as a cron job at 8:00am on Sundays:



allegra:peakFit>crontab -l








01 05 * * 0 cat /cvs/cds/caltech/users/kiwamu/work/20091026_OMC-LSC-diag/src/OMC_LSC_timing.m | matlab -nosplash -nodesktop > /dev/null

0 8 * * 0 /cvs/cds/rtcds/caltech/c1/scripts/SUS/peakFit/runDrSUS

Also: should these variable definitions really be here?



  5785   Wed Nov 2 14:07:25 2011 ZachUpdateelogrestarted

Elog was hanging, restarted with the script.

  5800   Thu Nov 3 17:24:59 2011 ZachUpdateGreen LockingSHG temperature (YARM)

I must confess that I changed the temperature of the laser via the dial yesterday. I believe the initial (displayed) temperature was ~19o, whereas it is now probably in the high 20s. Sorry.


Changing the crystal temperature changes the laser frequency. This will causes the beat note missing at the vertex.

In other words, you will find the beat note at the vertex when the actual temperature of the crystal is reproduced as before,
no matter how the dial setting/temp voltage input is.


  5805   Fri Nov 4 00:25:49 2011 ZachUpdateSUSDr. SUS paths updated--question of human oversight remains
  • I have replaced all instances of /cvs/cds/rtcds with /opt/rtcds in the Dr. SUS code. 
  • We discussed placing a human in charge of whether or not the input matrices get written to the frontend. I am not sure if we reached a definitive conclusion. Currently, the code is set to write the matrices automatically. What to do?
    • If we decide that oversight is necessary, I suggest that we leave the publishing of the results to the elog intact. This way, it will be someone's job to read the weekly Dr. SUS diagnosis on Sunday night (or Monday morning), and run a simple script that writes the matrices. This seems like the most reasonable solution.

I await responses...

  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.


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.


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.



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

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


  5936   Fri Nov 18 00:25:10 2011 ZachUpdateelogrestarted

 with script.

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

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

The changes were:

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

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


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

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



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

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

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


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

I wouldn't bother...

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


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

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

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

Here are a couple command examples:

1. Turning on the TEC output 

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

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

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

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

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

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

Here is an error spectrum:


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

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

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

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

So, how it works:

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

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

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

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

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



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


(AM transfer function)

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

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

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

[Jenne, Zach]

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

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

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

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

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

  5985   Wed Nov 23 00:30:55 2011 ZachUpdateelogsucks

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

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

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

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


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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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


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


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


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


 It is not obvious what is working.


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

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

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

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

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

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

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


ELOG V3.1.3-