Short entry just to preview a new development; more detail about this investigation will soon follow. 

The beatbox I and Q signals are too small at the ADC! I was able to reduce the RMS out of loop ALS sensitivity (arm locked on POX) by 300Hz with G=10 SR560s between the beatbox output and the ADC whitening chassis input. Increasing the beat note amplitude via RF amplifier had no positive effect. 

There is still a reasonable gap between this and the beatbox's noise levels, as measured with a marconi. There may be additional headroom for whitening gain; the SR560 maximum output range is smaller than the ADC input range. 

The high frequency noise has >0.5 coherence with the PDH error signal above a kHz or so, but not much below that. 

We should probably either modify the output whitening of the beatbox, or introduce some (variable?) whitening gain in a seperate circuit. 

Here are the promised details!

I was worried about the lack of whitening gain, as I saw that the DC phase tracker Q output (which is the magnitude of the signal in the beatbox's I-Q plane) was no more than 200 ADC counts for X (~120mV), and 800 for Y (~500mV). I.e. this is the largest DC value that either the I or Q ADC channels can see, and the RMS fluctuations are on the order of mV, meaning we're wasting our entire ADC range. 

However, I also had doubts about this since, even in the nominal state, the ASD of the ADC signals before dewhitening was higher than the expected ADC noise level. However, because of the non-linearity of the conversion of the BEAT_I and Q signals into the phase tracker output, evaluating the contribution of the beatbox output and ADC input voltage noises takes a few more steps. 

So, I hooked up a Marconi as the signal source for the beatbox's X channel , with no modulation (presumably the phase noise of the Marconi output is significantly lower than the sensitivity of the beatbox). For all of these measurements, the beat frequency was kept around 50MHz, with an amplitude of -30dBm on the control room analyzer, which is a typical X ALS operating point. 

At this point, the beatbox output noise was below the ADC noise (as measured by an SR785). Nevertheless, I found that the beat spectrum driven by the Marconi lined up to be very close to the ALS beat spectrum across a wide band, explaining much of the noise. 

Going back to the real green beat signal with the SR560s still at G=10, I obtained the result shown in ELOG 11355. I will soon repeat this process with the Y ALS. 

As I mentioned in the previous ELOG, we may be further helped by more whitening gain than can be provided by the SR560s (and we obviously need a robust long term circuit for this gain). If it then turns out we are limited by beatbox noise to a degree we are not happy with, we could perhaps look into reintroducing some RF gain into the X beat. As Koji mentions in ELOG 8855, the beatbox operates best at an RF input of around -4dBm.

Nice find!

We ought to use our noise model of the ALS signal chain to determine what the right gains are, rather than hunt and peck. More likely we'll start from the right gains.​

Once the gains and/or whitening filters make sense, maybe we'll see some effect from fixing the green PDH loops.

I pulled the beatbox from the 1X2 rack so that I could try to hack in some output whitening filters.  These are shamefully absent because of my mis-manufacturing of the power on the board.

Right now we're just using the MON output.  The MON output buffer (U10) is the only chip in the output section that's stuffed:

The power problem is that all the AD829s were drawn with their power lines reversed.  We fixed this by flipping the +15 and -15 power planes and not stuffing the differential output drivers (AD8672).

It's possible to hack in some resistors/capacitors around U10 to get us some filtering there.  It's also possible to just stuff U9, which is where the whitening is supposed to be, then just jump it's output over to the MON output jack.  That might be the cleanest solution, with the least amount of hacking on the board.

In any event, we really need to make a v2 of these boards ASAP.  Before we do that, though, we need to figure out what we're going to do with the "disco comparator" stage back near the RF input.  (There are also a bunch of other improvements that will be incorporated into v2).

I modified the beatbox according to this plan.  I stuffed the whitening filter stage (U9) as indicated in the schematic (I left out the C26 compensation cap which, according to the AD829 datasheet, is not actually needed for our application).  I also didn't have any 301 ohm resistors so I stuffed R18 with 332 ohm, which I think should be fine.

Instead of messing with the working monitor output that we have in place, I stuffed the J5 SMA connector and wired U9 output to it in a single-ended fashion (ie. I grounded the shield pins of J5 to the board since we're not driving it differentially).  I then connected J5 to the I/Q MON outputs on the front panel.  If there's a problem we can just rewire those back to the J4 MON outputs and recover exactly where we were last week.

It all checks out: 0 dB of gain at DC, 1 Hz zero, 10 Hz pole, with 20 dB of gain at high frequencies.

I installed it back in the rack, and reconnected X/Y ARM ALS beatnote inputs and the delay lines.  The I/Q outputs are now connected directly to the DAQ without going through any SR560s (so we recover four SR560s). 

I have been puzzled about the beat note level we get out of the BeatMouth for some time.

• The beat PD used is the Menlo FPD310.
• But the version we have is an obsolete version of the product, for which a manual is hard to find.
• Hence, I don't know the transimpedance/electrical characteristics of this PD.
• The optical damage threshold of the PD is quoted as 2mW, which is a number I have been careful not to exceed.
• But I've felt that the beat amplitude level we get out of this PD is far too low considering the amount of DC optical power (as measured with a fiber power meter) incident on the PD.
• After some emailing and online hunting, I've gathered some numbers for the PD which are now on the wiki.
• The fiber beam splitters we use inside the BeatMouth don't have PM fibers. There are 3 such splitters inside the BeatMouth. So the overlap efficiency on the PD is unknown.
• But even so, the beat levels I was seeing were too low.

I have pulled the box out in order to re-characterize the DC power levels incident on the PD, and also to change the gain setting on the PD to the lower gain which is more compatible with the level of optical power we have going into the BeatMouth. The modern catalog for the FPD310 (see wiki) suggests that the maximum output voltage swing of the PD is 1Vpp driving a 50ohm load. With 50% overlapping efficiency between the PSL and AUX beams, and 400 uW of optical power from each beam, I expect an output of 0.5Vpp. Even with perfect overlap, I expect 0.8Vpp. So these numbers seem reasonable.

I also plan to check the scaling of electrical beat amplitude to optical power for a couple of levels to see that these scale as expected...

Summary:

I did some more BeatMouth characterization. My primary objective was to do a power budget. Specifically, to measure the insertion loss of the mating sleeves and of the fiber beam splitters. All power numbers quoted in this elog are measured with the fiber power meter. Main takeaways:

• Measured insertion loss of all mating sleeves, which are ADAFCPMB2, are in agreement with the < 1dB spec. 1 dB in power is ~20%.
• But there is large variance in the above number, between different supposedly identical connectors.
• Measured insertion loss from input port to coupled ports of the fiber beamsplitters are slightly larger than spec (~3.5dB), when measured after mating the fiber beamsplitter (which has Hi1060 flex fiber) and PM980 fiber (which is what brings light to the BeatMouth).
• But measured insertion loss when mating is between Hi1060 flex fiber ends is more in line with the expected value of ~3.5dB.
• Isolation of fiber beam splitters seems to match the spec of >55dB.

Results:

• I used the fiber bringing 416uW of IR light from EY for this test.
• Insertion loss was measured by injecting the fiber light at one port and measuring the transmitted power at various other ports.
• In order to couple the fiber power meter across a single mating sleeve, I used a short (~1m) patch cable from newport (F-SY-C-1FCA). Technically, this is single mode fiber with the correct type of connector, FC/APC, but is not PM.
• See Attachment #2 for the labeling of the connectors which is how I refer to them in the table below.
• Lest there be confusion, I use the definition of insertion loss  .

Remarks / Questions:

1. Is there any way to systematically reduce the insertion loss? Like getting a better mating part?
2. Question for the fiber experts: How do we deal with the unused port of the beam-splitters? Right now, they are just capped. But as you can see in Attachment #1, the caps certainly don't block all the light. What are the implications of back-scattered light into the fiber on the ALS noise? I guess the beamsplitter itself has the spec'd 55dB directivity, so do we not care about this?

Summary:

• DC light power incident on beat PD is ~400uW from the PSL and ~300uW from EX.
• These numbers are consistent with measured mating sleeve and fiber coupler losses.
• However, I measure an RF beatnote of 80mVpp (= -18dBm). This corresponds to a mode matching efficiency of ~15%, assuming InGaAs efficiency of 0.65A/W.

I find this hard to believe.

Details:

• I took this opportunity to clean the fiber tips on the PSL table going into the BeatMouth.
• PSL light power going into the BeatMouth is 2.6mW. Of which ~400uW reaches the Beat PD (measured using my new front panel monitor port).
• Similarly, 1mW of EX light reaches the PSL table, of which ~300uW reaches the Beat PD.
• The RF amplifier gain is 20dB, and RF transimpedance is 50 ohms.
• Using the (electrical) 20dB coupled port on the front panel, I measured a beat signal with 8mVpp. So the actual beat note signal is 80mVpp.

Discussion:

As I see it, the possibilities are:

1. My measurement technique/calculation is wrong.
2. The beat PD is broken has optoelectronic different that is significantly different from specifications.
3. The non-PM fiber lengths inside the beat box result in ~15% overlap between the PSL and EX beams. Morever, there is insignificant variation in the electrical beat amplitude as monitored on the control room analyzer. So there is negligible change in the polarization state inside the BeatMouth.

I guess #3 can be tested by varying the polarization content of one of the input beams through 90 degrees.

[Yehonathan, Anchal]

On thursday Oct 21 2021, Yehonathan and I opened the door to BSC and took some photos. We setup the HEPA stand next to the door with anti-static curtains covering all sides. We spend about 15 minutes trying to understand the current layout and taking photos and a video. Any suggestions on improvement in our technique and approach would be helpful.

Links to photos:

https://photos.app.goo.gl/fkkdu9qAvH1g5boq6

There was only one razor blade beam dump labeled for atmospheric use left, but that's all we need. Steve is working on restocking. I placed the modified AOM mount on the PSL table near its intended location (near the AOM where it doesn't block any beams).

Things to keep in mind:

• The laser power needs to be turned down for the installation of the AOM. Current laser settings are: Crystal Temperature: 29.41 C, Diode Current: 2.1 A.
• The AOM driver must not be left unterminated when turned on (which it currently is and will be).
• The HEPA filters are currently running at ~50%. While the PSL enclosure is open for the work we'll set them to 100% and lower them after a job well done.

The setup:

The AOM has a deflection angle of about 20 mrad, which requires about 10cm of path for a separation of 2mm of the two beams. I need to survey closer and confirm, but I hope I can fit the beam dump in before the PMC (this of course also depends on the spot size). Alternatively, the PMC hopefully isn't resonant for anything remotely relevant at 80MHz offset, in which case we can also place the beam dump in its reflection path.

So this is the plan:

• Determine coupling efficiency into PMC for reference
• Turn down laser power
• No signal on AOM driver modulation input
• Mount AOM, place in beam path, and align
• Correct alignment into PMC?
• Secondary beam detectable? Adjust modulation input and laser power until detectable.
• Find a place for beam dump
• Confirm that primary beam is not clipping with PMC
• Turn up laser power
• Determine coupling efficiency with restored power to compare

Any thoughts? Based on the AOMs resting place I assumed that it is supposed to be installed before the PMC, but I'm actually not entirely sure where it was sitting before.

[Joe, Alex]

This morning I began the process of bringing our copy of the CDS code up to date to the version installed at Livingston. The motivation was to get fixes to various parts, among others such as the oscillator part.   This would mean cleaning up front end model .mdl files without having to pass clk, sin, cos channels for every optic through 3 layers of simulink boxes.

I also began the process of using a similar startup method, which involved creating /etc/init.d/ start and stop scripts for the various processes which get run on the front ends, including awgtpman and mx_streams.  This allows the monitor software called monit to remotely restart those processes or provide a web page with a real time status of those processes.  A cleaner rc.local file utilizing sub-scripts was also adapted.

I did some testing of the new codes on c1iscey.  This testing showed a problem with the timing part of the code, with cycles going very long.  We think it has something to do with the code not accounting for the fact that we do not have IRIG-B timing cards in the IO chassis providing GPS time, which the sites do have.  We rely on the computer clock and ntpd.

At the moment, we've reverted to svn revision 2174 of the CDS code, and I've put the previously working version of the c1scy and c1x05 (running on the c1iscey computer) back. Its from the /opt/rtcds/caltech/c1/target/c1x05/c1x05_11014_163146 directory.  I've put the old rc.local file back in /diskless/root/etc/ directory on the fb machine.  Currently running code on the other front end computers was not touched.

[JC, Jordan, Paco, Chub]

We began with the pumpdown this morning. We started with the annulus volume and proceeded by using the following:

1. Isolate the RGA Volume by closing of valves VM3 and V7.

2. Opened valves VASE, VASV, VABSSCT, VABS, VABSSCO, VAEV, and VAEE, in that order.

3. Open VA6 to allow P3, FRG3, and PAN to equalize.

4. Turn on RP1 and RP3, rough out annulus volume, once <1 torr turn on TP3. Close V6. Open V5 to pump the annulus volume with TP3.

5. Re route pumping from RP1 and RP3 to the main volume by opening V3 and slowly opening RV1.

6. After ~3.5 hours the pressure in the arms was <500mtorr on both FRG1 and P1a. Turn on TP1 and wait to reach full speed 560 Hz

7. Open V1 with RV2 barely open. The pressure diff between P1a and P2/FRG2 needs to be below 1 torr. This took a couple attempts with the manual valve in different positions. The interlocks were tripped for this reason. Repeat step 7 until the manual gate valve was in a position that throttled pumping enough to maintain the <1 torr differential.

8. Slowly open the manual gate valve over the course of ~ 1 hour. Once the manual gate valve fully opened, pressure in the arms was <1mtorr.

9. V7 was closed, leaving only TP2 to back TP1, while TP3 was used to continue pumping the annuli. Left in that configuration overnight (see attached)

We did have to replace gauge PAN becuase it was reading a signal error. In addition, we found the cable is a bit sketchy and has a sharp bend. The signal comes in and out when the cable is fiddled with.

[Jordan, JC]

Jordan and I went in to retore the Vacuum System back to it's original state before the power loss on June 8, 2022. The process went smoothly as we first closed V7 and opened VM3 (in that order).

The RP1/3 line did not have the KF blank installed. That was added and the RP flex line was capped off.

Symptoms:  Belladonna could not (for a while) connect to the wireless network, since there was a driver problem for the wireless card.  This (I believe) started when Yoichi was doing updates on it a while back.

The system: Belladonna is a Dell Inspirion E1505 laptop, with a Broadcom Corporation Dell Wireless 1390 WLAN Mini-PCI Card (rev 01)

Result:  Belladonna now can talk to it's wireless card, and is connected to the Martian network.  (MEDM and Dataviewer both work, so it must be on the network.)

What I did:

0.  Find a linux forum with the following method:  http://www.thelinuxpimp.com/main/index.php?name=News&file=article&sid=749

The person who wrote this has the exact same laptop, with the same wireless card.

1.  Get a new(er) version of ndiswrapper, which "translates" the Windows Driver for the wireless card to Linux-ese.  Belladonna previously was using ndiswrapper-1.37.

$wget http://nchc.dl.sourceforge.net/sourceforge/ndiswrapper/ndiswrapper-1.42.tar.gz

2.  Put the ndiswrapper in /home/controls/Drivers, and installed it.

$ndiswrapper -i bcmwl5.inf  3.  Get and put the Windows driver in /home/controls/Drivers/WiFi

$wget http://ftp.us.dell.com/network/R140747.EXE

4.  Unzip the driver

$unzip -a R140747.EXE

5.  Make Fedora use ndiswrapper

$ndiswrapper -m

$modprobe ndiswrapper

6. Change some files to make everything work:

/etc/sysconfig/wpa_supplicant      CHANGE FROM: DRIVERS="-Dndiswrapper"     CHANGE TO: DRIVERS="-Dwext"

/etc/sysconfig/network-scripts/ifcfg-wlan0      CHANGE FROM: BOOTPROTO=none      CHANGE TO: BOOTPROTO=dhcp

/etc/rc.d/init.d/wpa_supplicant        CHANGE FROM: daemon $prog -c $conf $INTERFACES $DRIVERS -B        CHANGE TO: daemon $prog -c$conf $INTERFACES $DRIVERS -B

6.  Restart things

$service wpa_supplicant restart
$service network restart

7.  Restart computer (since it wasn't working after 1-6, so give a restart a try)

8. Success!!!  MEDM and Dataviewer work without any wired internet connection => wireless card is all good again!

I bench tested the functionality of all the c1iscaux Acromag crate channels. Summary: we are not ready for a Monday install, much debugging remains.

1. DAC channels were tested using 4 ch oscilloscope and stepping the whitening gain sliders through their 15 gain settings
   • Response was satisfactory - the output changes between 0 - 5 V DC in 15 steps.
   • This analog voltage is converted to binary representation by an on-board ADC on the whitening boards. So we may have to tune the offset voltage and range to avoid accidental bit flipping due to the analog voltage of a particualr step falling close to the bit-flipping edge of the on-board ADC. This will require an in-situ test.
   • Test passed
2. BIO output channels were tested using a DMM, and monitoring the resistance between the BIO pin and the RTN pin. In the "ON" state, the expected resistance is ~5 Mohm, and in the off state, it is ~3 ohms.
   • The AA filter switches on BIO1 unit do not show the expected behavior - @ Chub, please check the wiring.
   • All others (except the mbboDirect bits, see next bullet) were okay, including those for the CM board that are NOT part of the mbboDirect groups.
   • Test failed
3. ADC channels were tested by driving a ~2Vpp 300mHz sine wave with a function generator, and looking at the corresponding EPICS channel with StripTool.
   • I found that all the ADC channels don't function as expected.
   • Part of the problem is due to incorrect formatting of the EPICS records in the db files, but I think the ADCs also need to be calibrated with the precision voltage source.
   • Why only ADCs require calibration and not the DACs????
   • Test failed
4. mbboDirect BIO output test - I made a little LED breadboard tester kit to simultaneously monitor the status of these groups of binary outputs.
   • The LSB is toggled as expected when moving the gain slider along.
   • However, the other bits in the group are not toggled correctly.
   • I believe this is a problem with either (i) the way the EPICS record is configured to address the bits or (ii) the incorrect modbus datatype is used to initialize the ioc.
   • It will be helpful if someone can look into this and get the mbboDirect bits working, I don't really want to spend more time on this.
   • Test failed

I am leaving the crate powered (by bench supplies) in the office area so I have the option to work remotely on this.

{Yehonathan, Jon, Jordan}

I tested the ai channels of the new PSL Acromag by looping an already-tested ao channel (C2:PSL-FSS-INOFFSET) back to the different ai channels.

I use Jon's IFOTest with /users/jon/ifotest/PSL.yaml.

I created a spreadsheet for the testing based on the current wiring spreadsheet. I added two columns for the high and low readings for each ai channel (attached pdf).

I marked in red the failed channels. Some of them are probably calibration issues, but the ones that show the same voltage for high and low are probably disconnected wires.

I redid the test on the channel that seemed disconnected to confirm.

I created a yaml file with all the failed channels for retesting called /users/jon/ifotest/PSL_failed_channels.yaml.

I checked the failed channels against the EPICS database definitions and the yaml file inputted to IFOTest. The channels where the readings are something other than +10/0 V, but the high/low values do change, I think can be attributed to one of two things:

• An incorrect gain and/or offset conversion parameter in the yaml file
• The EPICS SMOO parameter (smoothing) is set to some long value

I fixed the channel gains/offsets in the master yaml file (PSL.yaml). I also disabled smoothing in the EPICS defintions of the new PSL channels for the purpose of testing. We can uncomment those lines after installing the new chassis if noise is a problem. Please go ahead and re-test the channels again.

{Yehonathan, Jon}

We retested the failed ai channels. Most of them got fixed by applying the inverse calibration in the yaml file.

We still find some anomalous channels, mostly in the DB25 connector. Turns out, their limits were ill-defined in the EPICS database. Specifying the right limit fixed the issue.

We find one miswired channel (BNC4). We connected the BNC to the right channel on the Acromag unit which fixed the issue.

Overall all the ai channels were successfully bench-tested.

Today I bench-tested most of the Acromag channels in the replacement c1susaux. I connected a DB37 breakout board to each chassis feedthrough connector in turn and tested channels using a multimeter and calibrated voltage source. Today I got through all the digital output channels and analog input channels. Still remaining are the analog output channels, which I will finish tomorrow.

There have been a few wiring issues found so far, which are noted below.

Summary:

The mode-matching between the LO and AS beams is now ~50%. This isn't probably my most average mode-matching in the lab, but I think it's sufficient to start doing some other characterization and we can try squeezing out hopefully another 20-30% by putting the lenses on translation stages, tweaking alignment etc.

Details:

The main change was to increase the optical path length of the IFO AS path, see Attachment #1. This gave me some more room to put a lens and translate it.

• The LO path uses two lenses, f=200mm and f=100mm to focus the collimator output beam, which is supposedly ~1200um diameter, to something like 400um diameter (measured using beam profiler but not very precisely).
• This beam is  fairly well collimated, and the beam size is close to what the PMC cavity will want, I opted not to tweak this too much more.
• For the AS beam, the single bounce reflection from ITMY was used for alignment work.
• There is a 2" f=600mm lens upstream (not seen in Attachment #1). This supposedly makes a beam with waist ~80um, but I couldn't numerically find a good solution numerically if this assumption is true, so I decided to do the mode-matching empirically.
• A single f=150mm lens got me a beam that seemed pretty well collimated, and roughly the same size as the LO beam, so I opted to push ahead with that. Later, I measured with the beam profiler that the beam is ~600um in diameter, so the beam isn't very well matched to the LO spot size, but I decided to push ahead nevertheless.
• Patient alignment work enabled me to see interference fringes.
  • Note that the ITM reflection registers 30 cts (~80 uW). Assuming 800mW transmission through the IMC, I would have expected more like 800mW * 5.637% * 50% * 98.6% * 50% * 10% * 30% * 50% * 50% = 80uW, so this is reasonable I guess. The chain of numbers corresponds to T_PRM * T_BS * R_ITM * R_BS * T_SRM * T_vac_OMC_pickoff * R_in_air_BS * R_homodyneBS.
  • The IFO AS beam appears rather elliptical to the eye (and also on the beam profiler). It already looks like this coming out of the vacuum so not much we can do about it right now I guess. By slightly rotating the f=150mm focusing lens so that the beam going through it at ~10 degrees instead of normal incidence, I was able to get a more circular beam as measured using the beam profiler.
  • With the AS beam blocked, the LO beam registers 240 cts on each DCPD (~0.7 mW). 
  • The expected fringe should then be (sqrt(240) + sqrt(30))^2 - (sqrt(240) - sqrt(30))^2 ~ 440 cts pp.
  • The best alignment I could get is ~200 cts pp, see Attachment #2.

Next steps:

Try the PRMI experiments again, now that I have some confidence that the beams are actually interfering.

See Attachment #3 for the updated spectra - the configuration is PRMI locked with carrier resonant and the homodyne phase is uncontrolled. There is now much better clearance between the electronics noise and the MICH signal as measured in the DCPDs. The "LO only" trace is measured with the PSL shutter closed, so the laser frequency isn't slaved to the IMC length. I wonder why the RIN (seen in the SUM channel) is different whether the laser is locked to the IMC or not? The LO pickoff is before the IMC.

A better hysteresis model based on the simple harmonic oscillator equation. Useless variables have been removed and output can now be saved to workspace for plotting. The model is at "/users/mjenson/matlab/SHO_hyst.mdl".

[Jenne, Jamie, Manasa]

Today's activities focused on getting the POP layout improved, so that we could get clean data for the mode scan measurement. 

As Jamie and Koji pointed out yesterday, the beam was still a little too big on the POP DC PD, and was falling off the diode when the beam moved a small amount.  We have fixed things so that the PD is now at the focus of the lens, and the camera is at a place where the beam takes up most of the area on the TVs.  The beam no longer falls off the PD with cavity fluctuations.  A key point of this work was also to use an extra 2" optic to steer the beam down the length of the POP table, and then do the 50/50 beam splitting later with a 1" optic.  The 1" BS that we had been using (including with the "real" POP beam) is too small.  We could not find a 2" 50/50 BS, so we opted to do the splitting closer to the focal point.  Also, the BS that was splitting the beam between the PD and the camera was a 33% reflector, but now is a 50/50 BS. When we put back the 'real' POP path, we need to consider using larger optics, or a faster lens. The POP path is now good, hopefully for the duration of the half cavity test.

After getting the POP path taken care of, and tweaking up the cavity alignment a little bit, the transmitted power on POP DC is ~22,000 counts, with occasional fluctuations as high as 25,000 counts. 

Jamie looked at the REFL path, and things look sensible there.  The unlocked REFL power is ~36 counts, and the locked power is ~20 counts.  I'm not sure what the 160 counts that Koji mentioned in his edits to elog 7949 is about.

I looked at the PRM oplev with the cavity locked and unlocked, and with today's alignment, there seems to be no difference in the amount of PRM motion when the cavity is locked vs unlocked. 

 It still looks like we might be seeing some clipping in the in-vac POP steering mirrors - we haven't gotten to them yet.

Jamie is currently modifying Yuta's mode scan analysis script to look at the data that we have of the cavity.

We need more 2" optics.  There are no mounted 2" spares in the various optic "graveyards" (which, PS, we should consolidate all into the cabinet with doors near the optics bench), and the options for boxes in the drawers is slim pickin's.  We have some S-pol stuff, but no Y1s or BS-50s for P-pol.  Since POP, POX, POY, IPANG, TRX and TRY all come out of the vacuum with large beams, we should have some options for these laying around for this kind occasional temporary thing.  We also need to choose, then purchase better 2" lenses for the pickoffs.

With the newly repaired PDH board, I spent some time with the x arm green PDH loop. I found it SO MUCH EASIER to measure the OLTF by injecting before the servo, instead of after it. (i.e. I added a swept sine from the SR785 to the mixer output (error signal) before the servo input). This is likely because the error signal is much flatter. I used a 10mV excitation across the whole frequency range (30-100kHz). 

Here's the OLTF. I'm working on fitting it and breaking it up into its constituent TFs, then making a rudimentary noise budget. 

OK, the next question will be "why the loop bandwidth is so miserable?"
In other words, what is preventing us to have the bandwidth of 20~30kHz?
Your breaking down will give us the answer.

I'm not as good as a fit, but it seems that there is a loop delay of about 30 microseconds, looking at the high frequency phase. This might explain the limitation on the BW. Eric should be able to get the delay out of the fit with some care.

Yesterday I adjusted the preweighting of my IIR fit to the transfer function of MC2, and also managed to reduce the number of poles and zeros from 8 to 6, giving a smoother rolloff. The bode plots are pictured here:

The predicted IIR subtraction was very close to the predicted FIR subtraction, so I thought these coefficients would lead to a better online filter.

However, the actual subtraction of the MCL was not as good and noise was injected into the Y arm.

The final comparison of the subtraction factors between the online and offline data showed that the preweighting, while it improved the offline subtraction, needs more work to improve the online subtraction also.

Last night, I also worked on a "better" (an improvement, I thought) of the MISO Wiener filter (T240-X and T240-Y witnesses) IIR filter. The FF results are shown below:

Filter:

T240-X

T240-Y

Training data + Predicted FIR and IIR subtraction:

Online subtraction results:

MCL

YARM

Subtraction performace:

 Although the predicted FIR and IIR results are "better" than the previous MISO filter, the subtraction performance for this filter is marginally better if not worse (both peak at 15 dB, in slightly different regions). 

[Rana, Den, Mirko]

It seems you can shoot yourself in the foot if your filter modules are too complex.

Den discovered this when looking into the C1:SUS-MC?_SUSPOS filter module named Cheby, consisting of cheby1("LowPass",6,1,12)cheby1("LowPass",2,0.1,3)gain(1.13501) by noticing that the coherence between input and output of the filter is low.

Cheby filter:

This is most likely due to the filter spanning more than the 16 orders of precision that the double data type spans.

The coherence is fine when one splits the filter in two, giving every cheby1 filter its own module. The coherence is also fine when you use the Cheby filter in a 2kHz system, although the freq. response looks very odd

Black: 16kHz, Red 2kHz (yes the filter was converted correctly, no text file editing there)

The problem occurs on c1lsc as well as c1sus computer.

Looking into the foton files actually points to a precision problem, with the huge range of scale covered in there:

C1:MCS 16kHz (Cheby: Original filter with low coherence. CHbyTST & ChebyTST: Original filter split amongst two filter modules)
################################################################################
### SUS_MC3_LSC                                                              ###
################################################################################
# DESIGN   SUS_MC3_LSC 0 zpk([0],[30],0.333333,"n")
# DESIGN   SUS_MC3_LSC 1 cheby1("LowPass",6,1,12)
# DESIGN   SUS_MC3_LSC 2 cheby1("LowPass",2,0.1,3)gain(1.13501) \
#                       
# DESIGN   SUS_MC3_LSC 3 cheby1("LowPass",2,0.1,3)gain(1.13501)cheby1("LowPass",6,1,12)
# DESIGN   SUS_MC3_LSC 4 ellip("BandStop",4,1,40,16.1,16.9)ellip("BandStop",4,1,40,23.7,24.5)gain(1.25871)
###                                                                          ###
SUS_MC3_LSC 0 12 1  32768      0 30:0.0          9.942903833923793  -0.9885608209680459   0.0000000000000000  -1.0000000000000000   0.0000000000000000
SUS_MC3_LSC 1 21 3      0      0 CHbyTST     9.095012702673064e-18  -1.9978637592754149   0.9978663974923444   2.0000000000000000   1.0000000000000000
                                                                 -1.9984258494490537   0.9984376515442090   2.0000000000000000   1.0000000000000000
                                                                 -1.9994068831713223   0.9994278587363880   2.0000000000000000   1.0000000000000000
SUS_MC3_LSC 2 12 1  32768      0 ChebyTST    1.228759186937126e-06  -1.9972699801052749   0.9972743606395355   2.0000000000000000   1.0000000000000000
SUS_MC3_LSC 3 12 4  32768      0 Cheby       1.117558041371939e-23  -1.9972699801052749   0.9972743606395355   2.0000000000000000   1.0000000000000000
                                                                 -1.9978637592754149   0.9978663974923444   2.0000000000000000   1.0000000000000000
                                                                 -1.9984258494490537   0.9984376515442090   2.0000000000000000   1.0000000000000000
                                                                 -1.9994068831713223   0.9994278587363880   2.0000000000000000   1.0000000000000000
SUS_MC3_LSC 4 12 8  32768      0 BounceRoll     0.9991466189294013  -1.9996634951844035   0.9997010181703262  -1.9999611719719754   0.9999999999999997
                                                                 -1.9999303040590390   0.9999684339228864  -1.9999605309876360   0.9999999999999999
                                                                 -1.9999248796830529   0.9999668732412945  -1.9999594299327190   1.0000000000000002
                                                                 -1.9996385459838455   0.9996812069238987  -1.9999587601905868   1.0000000000000000
                                                                 -1.9996161812709703   0.9996978939989944  -1.9999163485656493   0.9999999999999999
                                                                 -1.9998855694973159   0.9999681878303275  -1.9999154056705493   0.9999999999999998
                                                                 -1.9998788577090287   0.9999671193335300  -1.9999137972442669   1.0000000000000000
                                                                 -1.9995951159123118   0.9996843310430819  -1.9999128255920269   1.0000000000000000

C1:OAF 2kHz
###############################################################################
### YARM_IN                                                                  ###
################################################################################
# DESIGN   YARM_IN 0 zpk([0],[30],0.333333,"n")
# DESIGN   YARM_IN 3 cheby1("LowPass",6,1,12)cheby1("LowPass",2,0.1,3)gain(1.13501)
# DESIGN   YARM_IN 4 ellip("BandStop",4,1,40,16.1,16.9)ellip("BandStop",4,1,40,23.7,24.5)gain(1.25871)
# DESIGN   YARM_IN 8 cheby1("LowPass",6,1,12)cheby1("LowPass",2,0.1,3)gain(1.13501)zpk([],[10],1,"n")
###                                                                          ###
YARM_IN  0 12 1   4096      0 30:0.0           9.56649943398763  -0.9119509539166185   0.0000000000000000  -1.0000000000000000   0.0000000000000000
YARM_IN  3 12 4   4096      0 Cheby       1.829878084970283e-16  -1.9828889048300398   0.9830565293861987   2.0000000000000000   1.0000000000000000
                                                                 -1.9868188576622443   0.9875701115261976   2.0000000000000000   1.0000000000000000
                                                                 -1.9940934073784453   0.9954330165532327   2.0000000000000000   1.0000000000000000
                                                                 -1.9781245722853238   0.9784022621062476   2.0000000000000000   1.0000000000000000

We replaced the complicated Cheby filter module with three separate filter modules. Probably the filter doesn't need to be so complicated, but rather not change too many things at once. The new filter modules are called:
Ch1, Ch2, Ch3 and are in filter module 3,9, and 10 of the C1:SUS-MC?_SUSPOS filters. The coherence with these filters is fine. Someone should look into the possibility of simplifying these filters.

It would be good to check for numerical problems in other filters!

 Could be that what we're seeing is the noise floor of the Direct Form II filter structure (see Matt's 2008 elog) which shows an example (also see G0900928-v1 ).

[Rana, Jenne]

Some of the funniness is some kind of mysterious interaction between 2 filter modules in the filter banks.  Just FM1 (30:0.0) or just FM4 (Cheby, which is 2 cheby1's) has reasonable coherence.  Both FM1 and FM4 together doesn't do so well - the coherence goes way down.

Just FM1 (30:0.0)

Just FM4 (Cheby)

 Both FM1 and FM4

 All the coherences plotted together

You'd think that the signal encounters FM1, gets filtered, and that result is the signal sent to the next active filter module, FM4, so the 2 filter modules shouldn't interact.  But clearly there's some funny business here since engaging both makes things crappy. 

Matlab investigations to replicate this behavior offline are in progress.

To see what might be causing the problem, I used a version of the filter noise test matlab code that Matt had in the elog.

To see if it was a single precision problem, I just recast the input data:   x = single(x)

This is not strictly correct, since some of the rest of the operations are as double precision, but I think that attached plot shows that a casting from double to single is close to the right amount of noise to explain our excess noise problem in the 0.1-1 Hz region.

Den is going to interview Alex to find out if we have some kind of issue like this. My understanding was that all of our filter module calculations were being done in double precision (64 bit), but its possible that some single stuff has crept back in. Currently the FIR filtering code IS single precision and in the past, the SUS code which didn't carry the LSC signals (meaning ASC and damping) were done in single precision.

Both Rolf and Alex (at least his elbow) together visited the 40m to talk with Joe for the CDS.

40m is the true front line of the CDS development!!!

[Jamie, Jenne]

We decided to take on the deceptively easy-sounding task of checking that the LSC whitening switching was happening as anticipated.  We hoped to discover that when we clicked the "unwhitening" switches in FM1 of the LSC PDs, we would see the analog whitening turn on and off for the matching channel.  That is what is supposed to happen.

Tragically, it is instead one big giant crazy disaster of a mess.

What we did:

Made a 24tapus (octopus like last time, except more...), with a 50kOhm resistor as our white noise source (instead of using a DAC channel and AWG). 

We plugged our 24tapus into the 3 of 4 whitening boards on the LSC rack that are currently in use.  One of the boards just has 8 terminators on the input, so we left that one alone for now. 

We put the whitening gains to 0dB so that all the channels looked the same. 

We looked at the PD _IN1 channels in DTT, and monitored which signals had whitening switching when we clicked the "unwhitening" buttons on the PD filter banks. 

So far, we can find no rhyme or reason as to why some of the channels work (click unwhite on that PD, see that signal have whitening switching), and others don't.  Some channels we just can't get to switch no matter what, others are just mis-mapped.  There is no discernible pattern.

What we think (so far) is going on:

All of the cables from the PD demod boards are going to the Whitening board inputs, exactly as in Suresh's Diagram.  The only difference is that Refl33, AS165 and Refl165 demod boards don't exist in the rack at this time. 

The Whitening and AA boards in Suresh's Diagram labeled 0-7 are connected to Binary Output channels 0-7. This is a good thing.

The Whitening and AA boards in the diagram labeled 8-15 are connected to Binary Output channels 24-31. This is not so awesome.

This is all we are confident about at this time.

Next steps:

We are hoping that Ben has a secret stash (or can tell us who would) of LSC rack wiring diagrams.  We would like to find out, without the pain of tracing wires and cables by hand, how the Binary I/O information gets through the cross-connect on the LSC rack up to the whitening boards. 

We are leaving the 24tapus in place for now, so that we can carry on tomorrow, either with a wiring diagram in hand, or carefully tracing cables. 

Remember, as per our marker board conversation, that the resistor noise as excitation method only works if the gain of all of the channels is set to something high (like 45 dB).

At 0 dB, the resistor noise is only 30 nV/rHz, whereas the ADC noise is more like 10000 nV/rHz...

I've been banging my head against bilinear noise subtraction, and figured I needed to test things on some real hardware to see if what I'm doing makes sense.

I ran the ASS dither alignment on the Y arm, which ensures that the beam spots are centered on both mirrors. 

I then drove ITMY in yaw with some noise bandpassed from 30-40 Hz. It showed the expected bilinear upconversion that you expect from angular noise on a centered beam, which you can see from 60-80 Hz below

I looked at the length signal, as the noise subtraction target, and the ITMY oplev yaw signal plus the transmon QPD yaw signal as witnesses.

There is some linear coupling to length, which means the the centering isn't perfect, and the drive is maybe large enough to displace it off center. However, the important part is the upconverted noise which is present only in the length signal. The QPD and oplev signals show no increased noise from 60-80Hz above the reference traces where no drive is applied

I then compared the multicoherence of those two angular witnesses vs. the multicoherence of the two (linear) witnesses plus their (bilinear) product. Including the bilinear term clearly shows coherence, and thereby subtraction potential, at the upconverted noise hump. 

So, it looks like the way I'm generating the bilinear signals and calculating coherence in my code isn't totally crazy.

[Nikhil, gautam]

We repeated the test that EricQ detailed here today. We have downloaded ~10min of data (between GPS times 11885925523 - 11885926117), and Nikhil will analyze it.

These are not the angular test parameters that we're looking for:

 recall that what we want is the low frequency beam spot variations and the feedback to be limited to a small high frequency band.

e.g. only inject noise at 40-50 Hz, not loud enough to find at 2x the injected frequency.

It should NOT be the case that the high frequency injected noise be dominating the RMS.

The coupling should be ~1e-3; some combination of beam spot mis-centering and beam spot motion.

[Steve / Kiwamu]

 When Steve was working on the strain reliefs on 1X5 he found that some LEDs on the back side of the binary IO boxes were off.

There are 4 binary IO boxes and their power are directly supplied from Sorensens. According to the display of the Sorensens, the power are correctly generated.

Steve and I checked a picture of the boxes taken before he started working and we found it's been like this.

It might be just a problem of the LEDs or the fuses are blown, but anyway it needs an inspection.

Here is a picture of the back side of the boxes. You can see some LEDs are on and some are off.

As noted previously, we were having problems with getting multiple 32 channel binary output cards working.  Alex came by and we eventually tracked the problem down to an incorrect counter in the c code.  This has been fixed and checked into the CDS svn repository.  I tested the actual hardware and we are in fact able to turn our test LEDs on with multiple binary output boards.

Alex and I also looked at the non-functional IO chassis (the one which wouldn't sync with the 1PPS signal and wasn't turning on when the computer turned on.  We discovered one corner of the trenton board wasn't screwed down and was in fact slightly warped.  I screwed it down properly, straightening the board out in the process.  After this, the IO chassis worked with a host interface board to the computer and started properly.  We were able to see the boards attached as well with lspci.  So that chassis looks to be in working condition now.

Onwards to the RFM test.

[ericq, gautam]

To diagnose the glitches in OSEM readouts, we have removed one of the PCIE BO D37 to IDE50 adaptor boxes from 1X5. All the watchdogs were turned off, and the power to the unit was cut before the cables on the front panel were removed. I am working on the diagnosis, I will update more later in the evening. Note that according to the c1sus model, the box we removed supplies backplane logic inputs that control whitening for ITMX, ITMY, BS and PRM (in case anyone is wondering/needs to restore damping to any of these optics). The whitening settings for the IMC mirrors resides on the other unit in 1X5, and should not be affected.

As we suspected, the binary breakout board (D080478, no drawing available) is simply a bunch of tracks printed on the PCB to route the DB37 connector pins to two IDE50 connectors. There was no visible damage to any of the tracks (some photos uploaded to the 40m picasa). Further, I checked the continuity between pins that should be connected using a DMM.

I got a slightly better understanding of how the binary output signal chain is - the relevant pages are 44 and 48 in the CONTEC manual. The diagram on pg44 maps the pins on the DB37 connector, while the diagram on pg 48 maps how the switching actually occurs. The "load" in our case is the 4.99kohm resistor on the PD whitening board D000210. Following the logic in the diagram on pg48 is easy - setting a "high" bit in the software should pull the load resistor to 0V while setting a "low" bit keeps the load at 15V (so effectively the whole setup of CONTEC card + breakout board + pull-up resistor can be viewed as a simple NOT gate, with the software bit as the input, and the output connected to the "IN" pin of the MAX333).

Since I was satisfied with the physical condition of the BO breakout board, I re-installed the box on 1X5. Then, with the help of a breakout board, I diagnosed the situation further - I monitored the voltage to the pins on the backplane connector to the whitening boards while switching the MEDM switches to toggle the whitening state. For all channels except ITMY UL, the behaviour was as expected, in line with the preceeding paragraph - the voltage swings between ~0V and ~15V. As mentioned in my post yesterday, the ITMY UL channel remains dodgy, with voltages of 12.84V (bit=1) and 10.79V (bit=0). So unless I am missing something, this must point to a faulty CONTEC card? We do have spares, do we want to replace this? It also looks like this problem has been present since at least 2011...

In any case, why should this lead to ITMY UL glitching? According to the MAX333 datasheet, the switch wants "low"<0.8V and "high">2.4V - so even if the CONTEC card is malfunctioning and the output is toggling between these two states, the condition should be that the whitening stage is always bypassed for this channel. The bypassed route works just fine, I measured the transfer function and it is unity as expected.

So what could possibly be leading to the glitches? I doubt that replacing the BO card will solve this problem. One possibility that came up in today's meeting is that perhaps the +24V to the Sat. Box. (which is used to derive the OSEM LED drive current) may be glitching - of course we have no monitor for this, but given that all the Sat. Amp. Adaptor boards are on 1X5 near the Acromag, perhaps Lydia and Johannes can recommission the PSL diagnostic Aromag to a power supply monitoring Acromag?

What do these glitches look like anyway? Here is a few second snapshot from one of the many MC1 excursions from yesterday - the original glitch itself is very fast, and then that gives an impulse to the damping loop which eventually damps away.

And here is one from when there was a glitch when the tester box was plugged in to the ITMY signal chain (so we can rule out anything in the vacuum, and also the satellite box itself as the glitches seem to remain even when boxes are shuffled around, and don't migrate with the box). So even though the real glitch happens in the UL channel (note the y axes are very different for the channels), the UR, LR and LL channels also "feel" it. recall that this is with the tester box (so no damping loops involved), and the fact that the side channel is more immune to it than the others is hard to explain. Could this just be electrical cross-coupling?

Still beats me what in the signal chain could cause this problem.

Some good news - Koji was running some tests on the modified WFS demod board and locked the IMC for this. We noticed that MC1 seemed well behaved for extended periods of time unlike last night. I realigned the PMC and IMC, and we have been having lock streches of a few hours as we usually have. I looked at the MC1 OSEM PD readbacks during the couple of lock losses in the last few hours, and didn't notice anything dramatic . So if things remain in this state, at least we can do other stuff with the IFO... I have plugged in the ITMY sat. box again, but have left the watchdog disabled, lets see what the glitching situation is overnight... The original ITMY sat. box has been plugged into the ETMY DAQ signal chain with a tester box. The 3 day trend supports the hypothesis the sat. box is not to blame. So I am plugging the ETMY suspension back in as well...

 I detached Clyde (pre-amp that was in the control room) to understand why it is not working. I seems that the board circuit is burnt near R40, R47, R45.

It looks like we should change the "R40" and "R47" diodes.  If you do it this week, ask Jamie or Koji to check that you've got them oriented correctly before soldering them and plugging it in.