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

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

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

What I did

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

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

/users/zach $ cd nds2-client-0.9.1

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

/users/zach $ sudo make

/users/zach $ sudo make install

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

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

$ sudo aptitude install lscsoft-auth

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

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

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

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

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

>> savepath

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

$ kinit albert.einstein %then enter password

$ matlab -nosplash -nodesktop

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

d = 

            name: 'H1:LSC-NPTRX_OUT16.mean' 

            chan_type: 'm-trend'             

            rate: 0.0167       

            data_type: 'real_8'     

            signal_gain: 1   

            signal_offset: 0     

            signal_slope: 1     

            signal_units: ''   

            start_gps_sec: 963968415     

            duration_sec: 6000             

            data: [100x1 double]           

            exists: 1

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

$ kdestroy % so that no one uses your credentials

Some thoughts

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>> L = [4.34 4.34];

>> RoC = [115.5 1e10];

>> theta = [0 0];

>> fmod = 11e6;

>> lambda = 1064e-9;

>> num_pts = 1000;

>> loss = 50e-6;

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

>> fmod = 55e6;

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

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

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

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

RA: NO, stil not OK.

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

model = arbcav(model);

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

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

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

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

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

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

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

OMC.in.lambda = 1064e-9;

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

OMC.in.f_mod = 24.5e6;

>> OMC

OMC = 

    in: [1x1 struct]

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

Warning: No loss given--assuming lossless mirrors 

> In arbcav at 274 

OMC = 

         in: [1x1 struct]

        FSR: 2.7353e+08

        Lrt: 1.0960

    finesse: 374.1568

    buildup: 119.6956

         df: [1000x1 double]

      coefs: [1000x4 double]

        HOM: [1x1 struct]

>> OMC.HOM

ans = 

      f: [1x1 struct]

    pwr: [1x1 struct]

>> OMC.HOM.pwr

ans = 

    carr: [15x15 double]

     SBp: [15x15 double]

     SBm: [15x15 double]

Some other notes:

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

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

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

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

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

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

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

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

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

R.I.P., AD743

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

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

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

with the script, as it was down.

Again.

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

I get:

DokuWiki Setup Error

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

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

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

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

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

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

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

As it stood, our options were:

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

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

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

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

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

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

 Two quadratures working in harmony.

 Hi Rana,

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

John   

Acromag Wireup Update

Channels no longer in use

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

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

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

Steps to return the OMC to the IFO output:

1. Complete non-Steve portions of the pre-vent checklist (https://wiki-40m.ligo.caltech.edu/vent/checklist)
2. Steve needs to complete his portions of the checklist (as in https://nodus.ligo.caltech.edu:8081/40m/12557)
3. Need to lock some things before making changes I think—but I’m not really sure about these, just going from what I can glean from the elogs around the last vent
   1. ​Lock the IMC at low power
   2. Align the arms to green
   3. Lock the arms
   4. Center op lev spots on QPDs
   5. Is there a separate checklist for these things? Seems this locking process happens every time there is a realignment or we start any work, which makes sense, so I expect it is standardized.
4. Turn/add optics in the reverse order that Gautam did
   1. ​Check table leveling first?
   2. Rotate OM5 to send the beam to the partially transmissive mirror that goes to the OMC; currently OM5 is sent directly to OM6. OM5 also likely needs to be translated forward slightly; Gautam tried to maintain 45 deg AOI on OM5/6.
   3. A razor beam dump was also removed, which should be replaced (see attachment 1 on https://nodus.ligo.caltech.edu:8081/40m/12568)
   4. May need to rotate OM6 to extract AS beam again, since it was rotated last time
   5. Replace the mirror just prior to the window on the AP table, mentioned here in attachment 3: https://nodus.ligo.caltech.edu:8081/40m/12566
      1. ​There is currently a rectangular weight on the table where the mirror was, for leveling
5. Since Gautam had initially made this change to avoid some backscattered beams and get a little extra power, we may need to add some beam dumps to kill ghosts
   1. This is also mentioned in 12566 linked above, the dumps are for back-reflection off the windows of the OMC
6. Center beam in new path
7. Check OMC table leveling
8. AS beam should be round on the camera, with no evidence of clipping on any optics in the path (especially check downstream of any changes)

• 27 or 29 total ADC channels are used (depending whether we keep 2 spare adc chans)
  • 4 each go to ASC_QPD1/2 (8 chans total)
  • 5 go to TRANS_PD1, TRANS_PD2, REFL_PD, TRANS_PD1_UF, TRANS_PD2_UF. These PD are used for ASC and LSC.
  • 2 go to the LSC, one each for DVMDC, DVMAC, X3DC, and X4DC
  • 12 go to the ASC_PZT
  • 2 go to the SPARE_ADC (not sure what this is)
  • I think these channels are (or were at some point) defined in memory by /cvs/cds/caltech/chans/ipc/G1.ipc
    • I found this from elog 2860; it mentions that these should eventually be migrated over to a file C1.ipc, but I don't see any OMC channels in that file or any of the 'old' C1.ipc files, so I suppose it never happened or they were removed later
  • During this vent, we won't have ASC, so
• 10 or 14 DAC channels are used (depending whether we keep 4 spare dac chans)
  • 2 from the LSC, one for CLK_OUT and one for "LSC"
  • 8 from ASC, including P1A, P1B, P2A, P2B, P1OSC, Y1OSC, P2OSC, Y2OSC
  • I think these channels are (or were at some point) saved to frames due to /cvs/cds/caltech/chans/daq/C1OMC.ini, which I found from elog 2073
  • At some point, the 33MHz mod depth was controlled by one of the spare OMC chans, C1:OMC-SPARE_DAC_CH_15. See elog 2126. I assume this is no longer the case, since c1omc is defunct.
  • Durnig this vent, we won't have ASC and don't need to CLK_OUT the LSC, so we may just need one DAC channel

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

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

Need to check:

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

I started this document on my own with notes as I was tracing the beam path through the output optics, as well as some notes as I started digging through the elogs. Let's just put it here instead....

1. Beam from AS port into OMMT
2. Reflect off OM5-PJ
   1. TO DO: check that the PZT works
   2. 40/P/F/L, 1525-45-P
3. Pick off from OMPO
   1. TO DO: determine how much power is needed for the pick off, choose an appropriate optic (for this vent probably 50-50 is fine)
   2. The PO beam goes to OM6
4. Reflect off MMT1???
   1. TO DO: determine if this mirror has a PZT, get it working
      1. Has a PZT?
      2. Which PZT channel on the DAQ?
      3. Is there a cable going to from the DAC to the PZT?
      4. Is the PZT functional?
      5. How many PZTs does this mirror actually have?
   2. TO DO: determine the real name of this optic, find its recent history in the elog
   3. TO DO: determine the correct telescope parameters to optimally couple into the mode cleaner given the following:
   4. TO DO: look up how the radius of curvature (RC) of the OMC has changed, and therefore what telescope parameters are necessary
5. Focused by MMT2???
   1. TO DO: determine if this mirror has a PZT
      1. Has a PZT?
      2. Which PZT channel on the DAQ?
      3. Is there a cable going to from the DAC to the PZT?
      4. Is the PZT functional?
      5. How many PZTs does this mirror actually have?
   2. TO DO: determine the real name of this optic, find its recent history in the elog
   3. TO DO: what about this optic is tunable? It looks bulky
6. Columnated by MMT3???
   1. TO DO: determine if this mirror has a PZT
      1. Has a PZT?
      2. Which PZT channel on the DAQ?
      3. Is there a cable going to from the DAC to the PZT?
      4. Is the PZT functional?
      5. How many PZTs does this mirror actually have?
7. Steered by MMT4???
   1. TO DO: determine the real name of this optic
   2. TO DO: why is this optic so small? Looks different from the rest, maybe weird space constraint
8. Steered by MMT5???
   1. TO DO: why is this optic so large compared to OMMT4?
   2. TO DO: is there a more space efficient way of steering this beam, or even some way that avoids having to steer with three distinct optics
9. Steered by MMT6???
   1. TO DO: Can this optic be removed with some clever new beam path?
10. Cleaned by the OMC
    1. TO DO: Where does the promptly reflected beam from OMC1 go after it exits the chamber?
    2. TO DO: check the PZTs
       1. Has a PZT?
       2. Which PZT channel on the DAQ?
       3. Is there a cable going to from the DAC to the PZT?
       4. Is the PZT functional?
       5. How many PZTs does the OMC actually have?
    3. TO DO: Determine if a new OMC configuration would be more ideal for the squeezing experiment
       1. This is a large task, not part of this immediate vent
    4. TO DO: What is done with the OMC reflection? What is done with the transmission?
    5. TO DO: Check the logs about how the OMC had been in use; should be mostly from rob ward
11. Reflected beam goes to the next chamber
12. Transmitted beam is split by OM7???
    1. TO DO: find the actual name of this optic
    2. TO DO: why does this have the R/T that is does?
13. Reflected beam goes to my OMPD
    1. TO DO: figure out what this PD is used for, and whether we even need it
       1. I think this might be the camera mentioned in 40m elog 21
       2. Elog 42 says the 4 QPDs for the OMC have meds screens located under C2TPT—is this a clue for channel names?
14. Transmitted beam is reflected to the next chamber by OM8???
    1. TO DO: determine the name of this optic
    2. TO DO: Where does this beam go? What is it used for?
15. Beam Dumps to add
    1. Transmission through OM5? Probably don’t need…
    2. OMMT1 transmission
    3. OMMT steering mirror transmissions
    4. OMC transmissions? Probably not?
    5. OMPD transmission?
    6. OM8 transmission
    7. Green scattering off of the window where the beam goes after GR_SM5
    8. Backscatter from the OMC prompt reflection to the window
    9. Backscatter from the OMC reflection to the window
    10. Backscatter from the MC beam off the window (this beam just travels through this chamber, interacts with no optics; there is also what looks like a small blue beam on this diagram, so maybe need to dump that backscatter too)
    11. Backscatter from the PO beam from OM6 going through the chamber window
    12. Backscatter from IM1 out the window
    13. There is a small blue beam from OMMT3 that goes through this window as well, I’m not sure exactly what is is from or for, or if it is physical (there are a few of these strange blue lines, i'm probably just misreading the diagram)
16. TESTS TO DO
    1. Characterize the PZT control
    2. Lock the OMC with a PZT dither lock
       1. Eg elog 59
    3. “Tap-tap-tappy-tap test” to find resonanes
       1. Look at combination of PDH error signal and DCPD signal???
       2. See elog 86 for results from initial OMC install—Nov 2007
    4. Check wiggling wires, etc
    5. TFs to check? Vertical TF?
    6. OMC Length check— see for eg elog 768
17. ADDITIONAL TO DO
    1. Mode matching calculation for new radius of curvature optics—see elog 1271
       1. The current MMT is not the optimal configuration even for the old Rc (see 3077 and 3088)

Notes during reading elog

• Entry 590 has a labelled picture of the optics setup with OMC
• Mention of omcepics at elog 894
• Some important changes happened in elog 1823
  • 1''->2'' mirror out of the vacuum--I should check whether this is still there, or if it has been moved
  • [many more changes.....]
• There were at one time 2 cameras monitoring OMCT and R (see 4492, 4493)
• Some OMC PZT HV supply info is at elog 4738, 4740... 
• There are some photos of the OMC table at elog 5120, and a note about moving some optics
• Not strictly about the OMC, but I really like Suresh's diagram 6756, I'll make something similar for the OMC electronics
  • although it is about adding the tip tilt electronics, which I think required a new flange for the OMC chamber
• OMC stage 1 and 2 are the steering mirrors going into the OMC, and were controlled by EPICS chans (6875, 6884)
  • these PZT HV supplies lived in OMC_SOUTH (or maybe 1Y3? see elog 6893), the driver in OMC_NORTH (LIGO-D060287)
  • Photos of these supplies in 7696
• There are pictures of the OMC and its PZTs in 7401
• The OMC HV supply was moved to power a different set of PZTs (see 7603)
• Talk of replacing the PZTs with picomotors or tip/tilts in 7684
• More pictures of the OMC table before the OMC was 'removed' are here (8114) and in 12563/12571 Gautam links to a Picassa album with pictures from just before the beam was diverted

We found a diagram describing the DC Readout wiring scheme on the wiki page for DC readout (THIS DIAGRAM LIED TO US). The wiring scheme is in D060096 on the old DCC.

Following this scheme for the OMC PZT Driver, we measured the capacitance across pins 1 and 14 on the driver end of the cable nominally going to the PZT (so we measured the capacitance of the cable and PZT) at 0.5nF. Gautam thought this seemed a bit low, and indeed a back of the envelope calculation says that the cable capacitance is enough to explain this entire capacitance.

Gautam has gone in to open up the HV driver box and check that the pinout diagram was correct. We could identify the PZT from Gautam's photos from vent 79, but couldn't tell if the wires were connected, so this may be something to check during the vent.

UPDATE:

Turns out the output was pins 13 and 25, we measured the capacitance again and got 209nF, which makes a lot more sense.

In preparation for tomorrow's vent, I'm checking some of the OMC-related electronics we plan to use.

First up is the HV Piezo Driver (D060283).

(well, technically the first up was the Kepco HV power supply... but I quickly tested that its output works up to 300V on a multimeter. The power supply for OMC-L-PZT is all good!)

According to the DCC, the nominal HV supply for this board is 200V; the board itself is printed with "+400V MAX", and the label on the HV supply says it was run at 250V. For now I'm applying 200V. I'm also supplying +-15V from a Tektronix supply.

I used two DB25 breakout boards to look at the pins for the DC and AC voltage monitors (OMC_Vmon_+/-, pins 1/6, and OMC_Vmon_AC+/-, pins 2 and 7) on a scope. I hooked up a DS345 function generator to the piezo drive inputn (pins 1,6). According to the 2013 diagram from the DCC, there is just one drive input, and an alternative "dither in" BNC that can override the DAC drive signal. I leave the alternative dither floating and am just talking to the DAC pins.

Aspects of the system seem to work. For example, I can apply a sine wave at the input, and watch on the AC monitor FFT as I shift the frequency. However, anything I do at DC seems to be filtered out. The DC output is always 150V (as long as 200V comes from the supply). I also notice that the sign of the DC mon is negative (when the Vmon_+ pin is kept high on the scope), even though when I measure the voltage directly with a multimeter the voltage has the expected (+) polarity.

A few things to try:

• The DC_Readout electronics scheme on the wiki has separate oscillator and control inputs. This diagram has lied to us in the past and is older, and the traces on top of the breadboard seem to only go to pins 1 and 6, but I'm going to first try to apply a voltage across pins 2 and 7 in case there actually is a separate control I'm ignoring.
  • Driving on these pins seems to do nothing

On further investigation this was the key clue. I had the wrong DCC document, this is an old version of this board, the actual board we are using is version A1 of D060283-x0 (one of the "other files")

Gautam and Koji returned at this point and we started going through the testpoints of the board, before quickly realizing that the DC voltage wasn't making it to the board. Turns out the cable was a "NULL" cable, so indeed the AC wasn't passing. We swapped out the cable, and tested the circuit with 30V from the HV supply to trim the voltage reference at U14. The minimum voltage we could get is 5V, due to the voltage divider to ground made by R39. We confirmed that the board, powered with 200V, can drive a sine wave and the DC and AC mons behave as expected.

[aaron, steve]

Steve gave me a venting tutorial. I'll record this in probably a bit more detail than is strictly necessary, so I can keep track of some of the minor details for future reference.

Here is Steve's checklist:

• Check that all jam nuts are tightened
• all viewports are closed
• op levs are off
• take a picture of the MEDM screens
• Check particle counts
• Check that the cranes work & wiped
• Check that HV is off

Gautam already did the pre-vent checks, and Steve took a screenshot of the IFO alignment, IMC alignment, master op lev screen, suspension condition, and shutter status to get a reference point. We later added the TT_CONTROL screen. Steve turned off all op levs.

We then went inside to do the mechanical checks

• N2 cylinders in the 40m antechamber are all full enough (have ~700psi/day of nitrogen)
• We manually record the particle count
  • this should be <10,000 on the 0.5um particles to be low enough to vent, otherwise we will contaminate the system
  • note: need to multiply the reading on the particle counter by 10 to get the true count
  • the temperature inside the PSL enclosure should be 23-24C +/- 3 degrees
  • We recorded the particle counts at ~830 and ~930, and the 0.5um count was up to ~3000
• We put a beam stop in front of the laser at the PSL table
• Checked that all HV supplies are either off or supplying something in air
  • we noticed four HV supplies on 1X1 that were on. Two were accounted for on the PSL table (FSS), and the other two were for C1IOO_ASC but ran along the upper cable rack. We got ahold of Gautam (sorry!) and he told us these go to the TT driver on OMC_SOUTH, where we verified the HV cables are disconnected. We took this to mean these HV supplies are not powering anything, and proceeded without turning these HV off.
  • There are HV supplies which were all either off or supplying something in-air at: 1Y4, 1Y2, OMC N rack, 1X9 (green steering HV)
• Checked that the crane works--both move up and down
  • vertex crane switch is on the wall at the inner corner of the IFO
  • y arm crane switch is on the N wall at the Y end
  • turn off the cranes at the control strip after verifying they work
• While walking around checking HV, we checked that the jam nuts and viewports are all closed
  • we replaced one viewport at the x arm that was open for a camera

After completing these checks, we grabbed a nitrogen cylinder and hooked it up to the VV1 filter. Steve gave me a rundown of how the vacuum system works. For my own memory, the oil pumps which provide the first level of roughing backstream below 500mtorr, so we typically turn on the turbo pumps (TP) below that level... just in case there is a calibrated leak to keep the pressure above 350mtorr at the oil pumps. TP2 has broken, so during this vent we'll install a manual valve so we can narrow the aperture that TP1 sees at V1 so we can hand off to the turbo at 500mtorr without overwhelming it. When the turbos have the pressure low enough, we open the mag lev pump. Close V1 if things screw up to protect the IFO. This 6" id manual gatevalve will allow us throttle the load on the small turbo while the maglev is taking over the pumping  The missmatch in pumping speed is 390/70 l/s [ maglev/varian D70 ]  We need to close down the conductive intake of the TP1 with manual gate valve so the 6x smaller turbo does not get overloaded...

We checked CC1, which read 7.2utorr.

Open the medm c0/ce/VacControl_BAK.adl to control the valves.

Steve tells me we are starting from vacuum normal state, but that some things are broken so it doesn't exactly match the state as described. In particular, VA6 is 'moving' because it has been disconnected and permanently closed to avoid pumping on the annulus. During this v ent, we will also keep pumping on the RGA since it is a short vent; steve logged the RGA yesterday.

We began the vent by following the vacuum normal to chamber open procedure.

1. VM1 closed
2. We didn't open VM3, because we want to keep the RGA on
3. Closed V1
4. Connect the N2 to the VV1 filter
   1. first puged the line with nitrogen
   2. We confirmed visually that V1 is closed
5. We opened VM2 to pump on the RGA with the mag lev pump.
   1. This is a nonstandard step because we are keeping the RGA pumped down.
   2. The current on TP3 is ~0.19A, which is a normal, low load on the pump
6. VV1 opened to begin the vent at ~10:30am
   1. use crescent wrench to open, torque wrench wheel to close
   2. Keep the pressure regulator below 10 psi for the vent. We started the vent with about 2psi, then increased to 8psi after confirming that the SUS sensors looked OK.
7. We checked the pressure plot and ITMX/ETMX motion to make sure we weren't venting too quickly or kicking the optics
   1. Should look at eg C1:SUS-ITMX_SENSOR_LL, as well as C1:Vac-P1_pressure
8. Once the pressure reaches 25torr, we switched over to dry air
   1. wipe off the outside dolly wheels with a wet rag, and exit through the x-arm door to get the air. Sweep off the area outside the door, and wipe off new air containers with the rag.
   2. Bring the cylinder inside, get the regulator ready/purged, and swap relatively quickly.
   3. We increased the vent speed to 10psi. 
   4. Steve says the vents typically take 4 of 300 cf cylinders from Airgas "Ultra Zero" AI  UZ300 that contains 0.1 PPM of THC

Everything looks good, so I'm monitoring the vent and swapping out cylinders.

At 12:08pm, the pressure was at 257 torr and I swapped out in a new cylinder.

Steve: Do not overpressurize the vacuum envelope! Stop around 720 Torr and let lab air do the rest. Our bellows are thin walled for seismic isolation.

Next check is the DCPD/OMMT Satellite Box

I traced a cable from the OMC electrical feedthrough flanges to find the DCPD/OMMT Satellite Box (D060105). I couldn't find the DCC number or mention of the box anywhere except this old elog.

Gautam and I supplied the box with power and tested what we think is the bias for the PD, but don't read any bias... we tracked down the problem to a suspicious cable, labelled.

We confirmed that the board supplies the +5V bias that Rich told us we should supply to the PDs.

We tested the TFs for the board from the PD input pins to output pins with a 100kHz low pass (attached, sorry no phase plots). The TFs look flat as expected. The unfiltered outputs of the board appear bandpassed; we couldn't identify why this was from the circuit diagram but didn't worry too much about it, as we can plan to use the low passed outputs.

I learned a lot about lasers this week from Siegman. Here are some plots that show the expected reflectivity off of the OMC for various mode matching cases.

The main equation to know is 11.29 in Siegman, the total reflection coefficient going into the cavity:

Where r is the mirror reflectivity (assumed all mirrors have the same reflectivity), t is the transmissivity, and g is the complex round-trip gain, eq 11.18

The second exponential is the loss; in Siegman the \alpha_0 is some absorption coecfficient and p is the total round trip length, so the product is just the total loss in a round trip, which I take to be 4*the loss on a single optic (50ppm each). \phi is the total round trip phase accumulation, which is 2\pi*detuning(Hz)/FSR. The parameters for the cavity can be found on the wiki.

I've added the ipynb to my personal git, but I can put it elsewhere if there is somewhere more appropriate. I think this is all OK, but let me know if something is not quite right.

Gautam and I tested out the DAC that he installed in the latter half of last week. We confirmed that at least one of the channels is can successfully drive a sine wave (ch10, 1-indexed). We had to measure the output directly on the SCSI connector (breakout in the FE hard drive cabinet along the Y arm), since the SCSI breakout box (D080303) seems not to be working (wiring diagram in Gautam's elog from his SURF years).

I've started putting together a list of things we'll need to buy to do BHD readout. I'm still messing around with more detailed optics layouts, but wanted to get a list started here so people can let me know if I'm missing any big, obvious categories of goods.

My current plan makes minimal changes to the signal path going to the OMC, and tries to just get the LO beam into the OMC with minimal optics. I'm not thinking of any of the optics as suspended, and it requires several reflections of the LO beam, so probably this is not an excellent configuration, but it's a start for getting the parts list:

1. My current thought is to use the MC reflection, the beam that heads from MC1 to MCR1, as the LO beam
   1. From MCR1, send the LO to a BS that directs it into an MMT, oriented along x (and lets us keep the MC refl PO)
   2. After the two MMT optics, the beam will be traveling along -x, and can be directed to a mirror that sends it towards -y to two steering mirrors that send it along -x then +x near the top of the table (perpendicular to the signal MMT.
   3. Then, send it to a PBS, which replaces the mirror directly after the signal MMT. This is where it combines 
2. Beam is then sent to the steering mirrors to bring it into the OMC
3. In parallel, the signal beam is going through the same path it has now, including the pickoff beam, with the one change that we need a HWP somewhere before the PBS, and the PBS replaces the mirror directly after the MMT (and needs to move a bit closer to have the beam properly directed)

I started making a layout of this scheme, but it's probably not going to work so I'm going to make a quick layout of this more major modification instead:

1. Both the MCR beam and the AS beam come in about parallel. Send each to a PO mirror.
2. The PO mirror directs both beams into parallel MMT aligned along x
3. From the MMT, each is directed to a pair of steering mirrors located where the OMC MMT is located now
4. From the steering mirrors go to the PBS that combines the signal and LO
5. Then to two more steering mirrors to get into the OMC, which may be moved towards +x
6. From the OMC go to the BHD PBS

What we need

Optics

• HWP for just before the LO combines with the signal
• HWP for just before the signal combines with the LO (is this necessary?)
• PBS to replace OM5 (combines the LO and the signal)
• Two MMT optics
• Two piezo-driven TT optics for steering the LO to the PBS
• One additional non-piezo optic for between the LOMMT and the LO-TTs
• One additional BS to get the LO into the MMT (and to let us still have the PO)
• -1 optic—we pick up one mirror that we replace with the PBS

Optomechanics

• 2x HWP mounts
• 1x PBS mount
• 2x mounts for piezo-driven TT
• 2x MMT optic mounts—I didn’t take a close enough look at these during the vent to know what we need here
• 2x mounts for ordinary optics
• 9x clamps for optics mounts (maybe fewer if some are on blocks)
• 9x posts for optics mounts

Electronics

• Additional TT driver
• HV supply for the new TTs
• Are the HWP actively controlled? We might need something to drive those?
• Do we have enough DAC/ADC channels?

Questions

These are mostly just miscellaneous

1. What of these optics need to be suspended? If we need suspensions on all of the LO optics, including the MMT, I’m not sure we’re going to be able to fit all of this on the table as I envision it…..
2. What if anything can we put out of vacuum (HWP for example)?
3. Do we actually need two MMT?

That seems fine, I wasn't thinking of that beam. in that case could we just have a PBS directly behind MMT2 and send both beams to the same OMMT?

Alternatively we can move OM5 and the beam path OMPO-OMMTSM towards -y, then put the LO-OMMT parallel to the existing OMMT but displaced in +x... we'd have to move the existing OMC and BHD towards +x as well. 

I've attached the diagram of what I mean.

There are a couple caveats and changes that would have to be made that are not included in this diagram, because they would be made on different tables.

1. I moved MMT2, which means the other MMT optics would have to be adjusted to accomodate this. I checked out the configuration on the BS table and this seems doable with a small rotation of MMT1 and maybe PJ2.
2. I don't know the best way to get the OMC REFL beam out... thoughts?
3. This diagram is kind of crappy after my edits, someone should tell me how to avoid collapsing all layers when I open these layout diagrams in inkscape, because I ended up editing the layout in Acrobat instead, where the lack of object grouping caused a bunch of the optics to lose one or two lines along the way.
4. I didn't include all beam paths explicitly but can if this looks like a good configuration.
5. The optic that picks off the transmission through MMT2 will need to move a bit, but there was a clamp in the way; this should be a minor change.
6. The optic just before the OMC needs to be moved up a bit.
7. The optic after the signal OMMT should be changed to a PBS and translated a bit; this is where the LO and signal beams will combine

Gautam also had some questions about the BHD/OMC timeline and plan. I feel somewhat on shaky ground with the answers, but figured I'd post them so I can be corrected once and for all.

1. Is the plan really to use the current OMC setup to make a homodyne measurement? 
   1. ​I'm not sure where on the timeline the new OMC and BHD switchover are relative to each other. I have been imagining doing the swap to BHD before having a new OMC.
2. I thought the current OMC resurrection plan was to do DC readout and not homodyne?
   1. ​I think the OMC resurrection plan is leading to DC readout, but when we switch over to BHD we'll be able to operate at the dark fringe. Is that right?
3. Is it really possible to use our single OMC to clean both the LO and dark port beams? Isn't this the whole raging debate for A+?
   1. ​My understanding is yes, with the LO and DP in orthogonal polarizations. It's not clear to me why we expect to be able to do this while there is a debate for A+, perhaps our requirements are weaker. It is something I should calculate, I'll talk to Koji.
4. A layout diagram would be really useful.
   1. ​Attached now.
5. Where in the priority list does this come in?
   1. ​I am a leaf in the wind. I think this comes well after we have the OMC resurrected, we just want to get a sense for what parts we need so we can order them before the fiscal year closes.

[aaron, gautam]

We finished up making the new c1omc model  (screenshot attached).

The new channels are only four DAC for ASC into the OMC, and one DAC for the OMC length:

I made a script to scan the OMC length at each setpoint for the two TTs steering into the OMC. It is currently located on nodus at /users/aaron/OMC/scripts/OMC_lockScan.py.

I haven't tested it and used some ez.write syntax that I hadn't used before, so I'll have to double check it.

My other qualm is that I start with all PZTs set at 0, and step around alternative +/- values on each PZT at the same magnitude (for example, at some value of PZT1_PIT, PZT1_YAW, PZT2_PIT, I'll scan PZT2_YAW=1, then PZT2_YAW=-1, then PZT2_YAW=2). If there's strong hysteresis in the PZTs, this might be a problem.

I'm continuing the arm loss measurements Yuki was making. I'm first familiarizing myself with the procedures for the measurement Johannes describes.

I'm not very familiar with the medm screens, so I'm just kind of poking around and checking with Gautam. I do the following:

1. Turned Xarm ASS dither on, then off.
2. Turned X and Y ALS on, then off shortly after
   1. Realizing I needed some guidance, I found this page on lock acquisition on the wiki
   2. Gautam showed me how to align/lock the IFO so I could take some notes, and we locked the Y arm, misaligned X.
3. I put the PD back in the AS beam path to get the ASDC signal, and approximately centered the beam. This PD is on channel 1 of the scope, which is at 192.168.113.24.
4. I centered the beam onto the MC2 PD that Yuki had installed. This PD is on channel 2 of the scope.
   1. Both scope channels are set to 1V scale (I also had tried 500mV, and it didn't seem to make a difference) and 10s time axis spacing (maximum integration time, since we're looking for a DC effect. Is this what we want?)
   2. The impedance for both channels is 1MOhm.
5. I ran the script to start the loss measurement on the Y arm.
   1. python2 armloss_dcrefl_asdcpd_scope.py 192.168.113.24 1 2 5 YARM
   2. I'm reading ~15 (au?) for the MC channel and ~5% of that out the AS, which seems to make sense to me and looked to be about what Yuki the ratios when I checked the log files. However, I'm a bit confused by the normalization, because the maximum output of the MC PD is 10V, and indeed the scope's display is reading under 10V.

I've left the script running.

After running this script Friday night, i noticed Saturday that the data hadn't saved. Scrolling up inthe terminal, I couldn't see where I'd run the script, so I thought I'd forgotten to run it as I was making last minute changes to the scope settings Friday before leaving.

Monday it turns out I hadn't forgotten to run the script, but the script itself was getting hung up as it waited for ASS to settle, due to the offset on the ETM PIT or YAW setpoints. The script was waiting until both pitch and yaw settled to below 0.7, but yaw was reading ~15; I think this is normal, and it looks like Yuki had solved this problem by waiting for the DEMOD-OFFSET to become small, rather than just the DEMOD signal to be small. Since this is a solved problem, I think I might be using an old script, but I'm pretty sure I'm running the one in Johannes' folder that Yuki is referencing for example here. The scripts in /yutaro_scripts/ have this DEMOD-OFFSET functionality commented out, and anyway those scripts seem to do the 2D loss maps rather than 1D loss measurements.

In the meantime I blocked the beams and ran the script in DARK mode. The script is saving data in /armloss/data/run_20181105/, and runs with no exceptions thrown.

However, when I try to dither align the YARM, I get an error that "this is not a degree of freedom that has an ASS". I'm alsogetting some exceptions from MEDM about unavailable channels. It must have been something about donatella not initializing, because it's working on pianosa. I turned on YARM ADS from pianosa. Monitoring from dataviewer, I see that LSC-TRY_OUT has some spikes to 0.5, but it's mostly staying near 0. I tried returning to the previous frozen outputs, and also stepping around ETMY-[PIT/YAW] from the IFO_ALIGN screen, but didn't see much change in the behavior of LSC-TRY. I missed the other controls Gautam was using to lock before, and I've also made myself unclear on whether ASS is acting only on angular dof, or also on length.

I unblocked the beams after the DARK run was done.

New all organic machine.

I'm checking out the data this morning, running armloss_AS_calc.py using the parameters Yuki used here.

I made the following changes to scripts (measurement script and calculator script)

• Included the 'hour' of the run in the armloss_dcrefl_* script. This way, we can run more than once a day without overwriting data.
• Changed the calculator script to loop over all iterations of locked/misaligned states, and calculate the loss for adjacent measurements.
  • That is, the measurement script will make a measurement with the arm locked, then with it misaligned, and repeat that N times
  • The calculator now finds the loss for the nth iteration using *_n_locked and *_n_misaligned, and finds N separate loss measurements
  • The dark signal is also computed N times, though all of the dark measurements are made before running the arm scripts, so they could be all integrated together.
  • All of these are saved in the same directory that the data was grabbed from.

I repeated the 'dark' measurements, because I need 20 files to run the script and the measurements before had the window on the scope set larger than the integration time in the script, so it was padded with bad values that were influencing the calculation.

On running the script again, I'm getting negative values for the loss. I removed the beamstops from the PDs, and re-centered the beams on the PDs to repeat the YARM measurements.

That was likely me. I had recentered the beam on the PD I'm using for the armloss measurements, and I probably moved the wrong steering mirror. The transmission from MC2 is sent to a steering mirror that directs it to the MC2 transmission QPD; the transmission from this steering mirror I direct to the armloss MC QPD (the second is what I was trying to adjust).

Note: The MC2 trans QPD goes out to a cable that is labelled MC2 op lev. This confusion should be fixed.

I realigned the MC and recentered the beam on the QPD. Indeed the beam on MC2 QPD was up and left, and the lock was lost pretty quickly, possibly because the beam wasn't centered. Lock was unstable for a while, and I rebooted C1PSL once during this process because the slow machine was unresponsive.

When tweaking the alignment near MC2, take care not to bump the table, as this also chang es the MC2 alignment.

Once the MC was stably locked, I was able to maximize MC transmission at ~15,400 counts. I then centered the spot on the MC2 trans QPD, and transmission dropped to ~14800 counts. After tweaking the alignment again, it was recovered to ~15,000 counts. Gautam then engaged the WFS servo and the beam was centered on MC2 trans QPD, transmission level dropped to ~14,900.

Gautam was doing some DRMI locking, so I replaced the photodiode at the AS port to begin loss measurements again.

I increased the resolution on the scope by selecting Average (512) mode. I was a bit confused by this, since Yuki was correct that I had only 4 digits recorded over ethernet, which made me think this was an i/o setting. However the sample acquisition setting was the only thing I could find on the tektronix scope or in its manual about improving vertical resolution. This didn't change the saved file, but I found the more extensive programming manual for the scope, which confirms that using average mode does increase the resolution... from 9 to 14 bits! I'm not even getting that many.

There's another setting for DATa:WIDth, that is the number of bytes per data point transferred from the scope.

I tried using the *.25 scope instead, no better results. Changing the vertical resolution directly doesn't change this either. I've also tried changing most of the ethernet settings. I don't think it's something on the scripts side, because I'm using the same scripts that apparently generated the most recent of Johannes' and Yuki's files; I did look through for eg tds3014b.py, and didn't see the resolution explicitly set. Indeed, I get 7 bits of resolution as that function specifies, but most of them aren't filled by the scope. This makes me think the problem is on the scope settings.

I began moving the AA and AI chassis over to 1X1/1X2 as outlined in the elog.

The chassis were mostly filled with empty cables. There was one cable attached to the output of a QPD interface board, but there was nothing attached to the input so it was clearly not in use and I disconnected it.

I also attach a picture of some of the SMA connectors I had to rotate to accommodate the chassis in their new locations.

Update:

The chassis are installed, and the anti-imaging chassis can be seen second from the top; the anti-aliasing chassis can be seen 7th from the top.

I need to breakout the SCSI on the back of the AA chassis, because ADC breakout board only has a DB36 adapter available; the other cables are occupied by the signals from the WFS dewhitening outputs.

I ran a BNC from the PD on the AS table along the cable rack to a free ADC channel on the LSC whitening board. I lay the BNC on top of the other cables in the rack, so as not to disturb anything. I also was careful not to touch the other cables on the LSC whitening board when I plugged in my BNC. The PD now reads out to... a mystery channel. The mystery channel goes then to c1lsc ADC0 channels 9-16 (since the BNC goes to input 8, it should be #16). To find the channel, I opened the c1lsc model and found that adc0 channel 15 (0-indexed in the model) goes to a terminator.

Rather than mess with the LSC model, Gautam freed up C1:ALS-BEATY_FINE_I, and I'm reading out the AS signal there.

I misaligned the x-arm then re-installed the AS PO PD, using the scope to center the beam then connecting it to the BNC to (first the mystery channel, then BEATY). I turned off all the lights.

I went to misalign the x-arms, but the some of the control channels are white boxed. The only working screen is on pianosa.

The noise on the AS signal is much larger than that on the MC trans signal, and the DC difference for misaligned vs locked states is much less than the RMS (spectrum attached); the coherence between MC trans and AS is low. However, after estimating that for ~30ppm the locked vs misaligned states should only be ~0.3-0.4% different, and double checking that we are well above ADC and dark noise (blocked the beam, took another spectrum) and not saturating the PD, these observations started to make more sense.

To make the measurement in cds, I also made the following changes to a copy opf Johannes' assess_armloss_refl.py that I placed in /opt/rtcds/caltech/c1/scripts/lossmap_scripts/armloss_cds/   :

• function now takes as argument the number of averages, averaging time, channel of the AS PD, and YARM|XARM|DARK.
• made the data save to my directory, in /users/aaron/40m/data/armloss/

I started taking a measurement, but quickly realized that the mode cleaner has been locked to a higher order mode for about an hour, so I spend some time moving the MC. It would repeatedly lock on the 00 mode, but the alignment must be bad because the transmission fluctuates between 300 and 1400, and the lock only lasts about 5 minutes.

Back to loss measurements.

I replaced the PD I've been using for the AS beam.

I misaligned the x arm.

I tried to lock the y arm, but PRC was locked so I could was unable. Gautam reminded me where the config scripts are.

The armloss measurement script needed two additional modifications:

• It was setting the initial offset of the PIT and YAW demod signals to 0, but due to the clipping on the heater we are operating at an offset. I commented out these lines.
• When the script ran UNFREEZE_DITHER, it was running it using medmrun. The scope script hadn't been using this, and it seemed that when it ran UNFREEZE_DITHER in this way the YARM_ASS servo was passing only '0'. I don't really know why this was, but when I removed the call to medmrun it worked.

I ran successfully the loss measurement script for the x and y arms. I'm getting losses of ~100ppm from the first estimates.

I made the following changes to the lossmap script:

• make the averaging time an input to the script, so we can exceed 2 second averages
• remove anything about getting data from the scope, replace it with the correct analogues to save the averages for POX/POY refl, MC trans, op lev P/Y, and ASDC signal.
• record the GPS time in the file with the cds averages (this way I can grab the full data)
• Added a step in the lossmap script to misalign the optic, so we can continue getting data for the 'misaligned' state, both for the centered and not-centered measurements (that is, for every position on the lossmap).

When the optic aligns itself not at the ideal position, I'm noticing that it often locks on a 01. When the cavity is then misaligned and restored, it can no longer obtain lock. To fix this, I've moved my 'save' commands to just before the loop begins. This means the script may take longer to run, but as long as the cavity is initially locked and well aligned, this should make it more robust against wandering off and never reacquiring lock.

I left the lossmap script running for the x-arm. Next would be to run it for the y arm, but I see that after stepping to a few positions the lock is again lost. It's still trying to run, but if you want to stop it no data already taken will be lost. To stop it, go to the remaining terminal open on rossa and ctrl+c

the analysis needs:

• Windowing
• Filter, don't average
• detrend to get rid of the linear drifts in lock that we see.
  • Is this the right thing?

I made additional measurements on the x and y arms, at 5 offset positions for each arm (along with 6 measurements at the "zeroed" position).

I finished running the cabling for the OMC, which involved running 7x 50ft DB9 cables from the OMC_NORTH rack to the 1X2 rack, laying cables over others on the tray. I tried not to move other cables to the extent I could, and I didn't run the new cables under any old cables. I attach a sketch diagram of where these cables are going, not inclusive of the entire DAC/ADC signal path.

I also had to open up the AA board (D050387, D050374), because it had an IPC connector rather than the DB37 that I needed to connect. The DAC sends signals to a breakout board that is in use (D080302) and had a DB37 output free (though note this carries only 4 DAC channels). I opened up the AA board and it had two IPC 40s connected to an adapter to the final IPC 70 output. I replaced the IPC40 connectors with DB37 breakouts, and made a new slot (I couldn't find a DB37 punch, so this is not great...) on the front panel for one of them, so I can attach it to the breakout board.

I noticed there were many unused wires, so I had to confirm that I had the wiring correct (still haven't confirmed by driving the channels, but will do). There was no DCC for D080302, but I grabbed the diagrams for the whitening boards it was connected to (D020432) and for the AA board I was opening up as well as checked out elog 8814, and I think I got it. I'll confirm this manually and make a diagram if it's not fake news.

I replaced the projector bulb. Previous bulb was shattered.

I've started testing the OMC channels I'll use.

I needed to update the model, because I was getting "Unable to setup testpoint" errors for the DAC channels that I had created earlier, and didn't have any ADC channels yet defined. I attach a screenshot of the new model. I ran

I need to hookup +/- 24 V supplies to the OMC whitening/dewhitening boxes that have been added to 1X2.

There are trailing +24V fuse slots, so I will extend that row to leave the same number of slots open.

While removing one +24V wire to add to the daisy chain, I let the wire brush an exposed conductor on the ground side, causing a spark. FSS_PCDRIVE and FSS_FAST are at different levels than before this spark. The 24V sorensens have the same currents as before according to the labels. Gautam advised me to remove the final fuse in the daisy chain before adding additional links.

gautam: we peeled off some outdated labels from the Sorensens in 1X1 such that each unit now has only 1 label visible reflecting the voltage and current. Aaron will post a photo after his work.