40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 40m Log, Page 37 of 341 Not logged in
ID Date Author Type Category Subject
13817   Fri May 4 21:17:57 2018 gautamConfigurationALSBeathMouth pulled out of PSL table

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

13824   Tue May 8 00:40:51 2018 gautamConfigurationALSBeathMouth pulled out of PSL table

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  $\mathrm{Insertion ~loss [dB] }=10\mathrm{log_{10}}(\frac{P_{in}}{P_{out}})$.
Mating Sleeve # Insertion loss [dB]
1 0.38
2 0.65
3 0.71
4 0.43
5 0.95
6 0.79
7 0.5

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?
Attachment 1: IMG_6986.JPG
Attachment 2: IMG_6987.JPG
13889   Thu May 24 19:41:28 2018 gautamConfigurationALSBeathMouth reinstalled on PSL table

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.

634   Thu Jul 3 18:48:09 2008 AlbertoUpdateGeneralBeats of the two lasers in the absolute length measurement observed
I adjusted the alignment of the flipper mirror as suggested by Koji making the two beam spots match. I also aligned all the IFO mirrors (ITMs, PRM, SRM, ETMs) to have more power for the IFO signal at the AS port. When I did that I could see the beats at the AS OSA. Then I explored the range of temperature of the NPRO from 35deg (C) to 51.2807deg and at that point I could observe a peak corresponding to the beat at about 10MHz on the network analyzer. The peak tends to drift because the laser takes probably a longer time to actually thermalize and it moves very rapidly changing the temperature of the laser.
635   Thu Jul 3 22:54:45 2008 KojiUpdateGeneralBeats of the two lasers in the absolute length measurement observed
Great! Conguraturation! I wish if I could see it! It's nice if you can put the photo or anything of the RF spectrum analyzer.

Next step:
o You can try to maximize the beat amplitude by the tuning of the Injection steering mirrors.

o At the south end of the SP table, I prepared a frequency mixer. You can put the beat signal into the RF input, and an oscillator (which you can bring from somewhere) to the LO input in order to obtain the error signal of the PLL. Put the IF output of the mixer in a SR560, and please try to lock it by a simple 6db/oct (1st order) LPF of the SR560. For the actuator you can use the fast-pzt input of the NPRO.

 Quote: Then I explored the range of temperature of the NPRO from 35deg (C) to 51.2807deg and at that point I could observe a peak corresponding to the beat at about 10MHz on the network analyzer.
637   Mon Jul 7 11:22:02 2008 AlbertoUpdateGeneralBeats of the two lasers in the absolute length measurement observed
I didn't post a screenshot from the RF SA because I had troubles with the interface with the computer (unfortunately the network SA cannot export the data either).

There is problem with the PLL circuit. The signal, beside the beat, also contains peaks at 33, 66 and 99 MHz, so we should think about filtering those out.

Quote:
Great! Conguraturation! I wish if I could see it! It's nice if you can put the photo or anything of the RF spectrum analyzer.

Next step:
o You can try to maximize the beat amplitude by the tuning of the Injection steering mirrors.

o At the south end of the SP table, I prepared a frequency mixer. You can put the beat signal into the RF input, and an oscillator (which you can bring from somewhere) to the LO input in order to obtain the error signal of the PLL. Put the IF output of the mixer in a SR560, and please try to lock it by a simple 6db/oct (1st order) LPF of the SR560. For the actuator you can use the fast-pzt input of the NPRO.

 Quote: Then I explored the range of temperature of the NPRO from 35deg (C) to 51.2807deg and at that point I could observe a peak corresponding to the beat at about 10MHz on the network analyzer.
638   Mon Jul 7 13:06:38 2008 KojiUpdateGeneralBeats of the two lasers in the absolute length measurement observed
One may need an RF filter after the mixer. I expect the SR560 does work for this purpose.
If it does not, a passive LPF can be used.

 Quote: I didn't post a screenshot from the RF SA because I had troubles with the interface with the computer (unfortunately the network SA cannot export the data). There's is problem with the PLL circuit. The signal, beside the beat, also contains peaks at 33, 66 and 99 MHz, so we should think about filtering those out, correct?
16424   Mon Oct 25 13:23:45 2021 AnchalSummaryBHDBefore photos of BSC

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

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

12192   Thu Jun 16 18:08:57 2016 JohannesUpdatePSLBefore the AOM installation

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.

4291   Mon Feb 14 18:27:39 2011 josephbUpdateCDSBegan updating to latest CDS svn, reverted to previous state

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

16871   Tue May 24 11:04:53 2022 JCUpdateVACBeginning Pumpdown

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

Attachment 1: PUMPDOWN-2022-05-24_16-57-59.png
Attachment 2: C1VAC_Screenshot_2022-05-24_16-59-27.png
16916   Wed Jun 15 07:26:35 2022 JCUpdateVACBeginning Pumpdown

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

 Quote: [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.

1275   Thu Feb 5 16:21:07 2009 JenneFrogsComputersBelladonna connects to the wireless Martian network again

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!

14840   Sun Aug 11 11:47:42 2019 gautamUpdateCDSBench test of c1iscaux

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.

15186   Tue Feb 4 18:13:01 2020 YehonathanUpdatePSLBench testing of PSL ai channels

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

Attachment 1: c1psl_wire_testing_-_By_Connector.pdf
15187   Wed Feb 5 08:57:11 2020 YehonathanUpdatePSLBench testing of PSL ai channels

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.

 Quote: 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.
15189   Wed Feb 5 21:04:10 2020 YehonathanUpdatePSLBench testing of PSL ai channels

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

Quote:

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.

 Quote: 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.
14561   Mon Apr 22 21:33:17 2019 JonUpdateSUSBench testing of c1susaux replacement

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.

Channel Type Issue
C1:SUS2-PRM_URVMon Analog input No response
C1:SUS2-PRM_LRVMon Analog input No response
C1:SUS2-BS_UL_ENABLE Digital output Crossed with LR
C1:SUS2-BS_LL_ENABLE Digital output Crossed with UR
C1:SUS2-BS_UR_ENABLE Digital output Crossed with LL
C1:SUS2-BS_LR_ENABLE Digital output Crossed with UL
C1:SUS2-ITMY_SideVMon Analog input Polarity reversed
C1:SUS2-MC2_UR_ENABLE Digital output Crossed with LR
C1:SUS2-MC2_LR_ENABLE Digital output Crossed with UR

15535   Fri Aug 21 15:27:00 2020 gautamUpdateBHDBetter BHD mode-matching

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.

Attachment 1: IMG_7548.JPG
Attachment 2: BHD_MM.png
Attachment 3: PRMI_DCPDs.pdf
6485   Wed Apr 4 21:43:16 2012 Mike J.UpdateComputersBetter Hysteresis Model

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

Attachment 1: SHO_hyst.png
7957   Tue Jan 29 19:50:49 2013 JenneUpdateLockingBetter POP layout, no extra PRM motion with locked cavity

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

Attachment 1: HalfPRCL_PRM-flatMirror_RefsAreLocked_OthersUnlocked.pdf
9459   Thu Dec 12 21:23:15 2013 ericqUpdateGreen LockingBetter Xarm OLTF

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.

9461   Thu Dec 12 22:12:17 2013 KojiUpdateGreen LockingBetter Xarm OLTF

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?

9464   Fri Dec 13 11:47:11 2013 GabrieleUpdateGreen LockingBetter Xarm OLTF

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.

860   Wed Aug 20 12:04:47 2008 JenneUpdateSUSBetter diagonalization of PRM input matrix
The values here should replace those in entry #851 from yesterday.

After checking the results of the input matrix diagonalization, I have determined that Sonia's method (described in LIGO-T070168) is more effective at isolating the eigenmodes than Shihori's method (LIGO-T040054).

So, the actual new PRM input matrices are as follows:

 POS PIT YAW UL 0.9678 1.000 0.7321 UR 1.000 0.8025 -0.9993 LR 0.7235 -1.1230 -1.0129 LL 0.6648 -1.0452 1.0000

Attached are plots of the spectra of the eigenmodes, using both Shihori's and Sonia's methods. Note that there isn't a good way to get the side peak out of the eigenmodes.

I've put these into the SUS-PRM MEDM screen.
Attachment 1: PRM_Eigmodes_shihori.png
Attachment 2: PRM_Eigmodes_sonia.png
1237   Mon Jan 19 13:58:53 2009 YoichiUpdateASCBetter ditherServo.pl
Nick Smith (@LHO) tested the ditherServo.pl at Hanford.
He added options to specify exit conditions to the script. Now you can make the script exit when
a condition, such as ArmPower > 1.0, is satisfied, or let it wait until a certain condition is satisfied.

I also modified the script to use ezcastep instead of tdswrite for feedback actuation.
The script now runs ezcastep in the background while the next iteration of the tdsdmd is performed.
Instead of kicking mirrors with a big thrust each time by a single tdswrite command, ezcastep gently moves the mirrors with fine steps.
I also implemented this "background ezcastep" technique in Tobin's tdscntr.pl.

The alignment scripts run smoother now.
11502   Thu Aug 13 12:06:39 2015 Jessica SummaryIOOBetter predicted subtraction did not work as well Online

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.

Attachment 1: newBodeX.png
Attachment 2: newBodeY.png
Attachment 3: pred_Sub.png
Attachment 4: MCLSub.png
Attachment 5: YarmSub.png
Attachment 6: comparison.png
11500   Wed Aug 12 16:48:26 2015 IgnacioUpdateIOOBetter? Nope. MISO WIener (T240-X and T240-Y) FF of MCL

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

Attachment 1: stsx.png
Attachment 2: stsy.png
Attachment 3: performance.png
Attachment 4: mcliir.png
Attachment 5: yarmiir.png
Attachment 6: sub.png
6011   Fri Nov 25 22:11:12 2011 MirkoUpdateCDSBeware of fancy filter modules

[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

Attachment 1: ChebyTST3.png
6013   Sat Nov 26 02:05:43 2011 MirkoUpdateCDSBeware of fancy filter modules

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!

6017   Sat Nov 26 10:55:40 2011 ranaUpdateCDSBeware of fancy filter modules

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

6030   Mon Nov 28 19:24:51 2011 JenneUpdateCDSBeware of fancy filter modules

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

Attachment 4: SUSPOS_ETMY_30and0andCheby_compareCoherence.pdf
6031   Mon Nov 28 22:09:24 2011 ranaUpdateCDSBeware of fancy filter modules

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.

Attachment 1: noise.pdf
3671   Thu Oct 7 16:21:02 2010 KojiOmnistructureCDSBig 3

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

Attachment 1: IMG_3642.jpg
4984   Mon Jul 18 20:59:19 2011 JenneUpdateLSCBig ol' mess

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

4988   Tue Jul 19 10:18:24 2011 ranaUpdateLSCBig ol' mess

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

12059   Fri Apr 1 13:11:26 2016 ericqUpdateWienerFilteringBilinear Noise Testing

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.

Attachment 1: bilinear_drive.pdf
Attachment 2: 40m_bilin.pdf
13167   Fri Aug 4 18:25:15 2017 gautamUpdateGeneralBilinear noise coupling

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

Attachment 1: bilinearTest.pdf
13169   Mon Aug 7 16:00:41 2017 ranaUpdateGeneralBilinear noise coupling

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.

4754   Fri May 20 03:29:04 2011 kiwamuUpdateCDSBinary IO box on 1X5 : LEDs off

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

3534   Tue Sep 7 15:31:28 2010 josephb, alexUpdateCDSBinary Output working/ IO chassis fixed

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.

12652   Wed Nov 30 17:08:56 2016 gautamUpdateLSCBinary output breakout box removed

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

12653   Thu Dec 1 02:19:13 2016 gautamUpdateLSCBinary output breakout box restored

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

Attachment 4: ULcomparison.pdf
6564   Tue Apr 24 22:16:59 2012 DenUpdatePEMBlue Bird Pre-Amplifier

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.

6566   Wed Apr 25 11:45:34 2012 JenneUpdatePEMBlue Bird Pre-Amplifier

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.

6567   Wed Apr 25 18:59:47 2012 ranaUpdatePEMBlue Bird Pre-Amplifier

Usually R is for resistors and D is for diodes. Do you think from the schematic that we should put diodes into the R slots?

6568   Wed Apr 25 19:32:57 2012 DenUpdatePEMBlue Bird Pre-Amplifier

 Quote: Usually R is for resistors and D is for diodes. Do you think from the schematic that we should put diodes into the R slots?

That guys are resistors.

6572   Thu Apr 26 11:56:10 2012 DenUpdatePEMBlue Bird Pre-Amplifier

Quote:

 Quote: Usually R is for resistors and D is for diodes. Do you think from the schematic that we should put diodes into the R slots?

That guys are resistors.

You are right, they just looked like they were too small to be resistors when I glanced at them.

3586   Sun Sep 19 18:09:09 2010 ranaConfigurationCamerasBlue IP Camera installed on the PSL table

I installed the blue IP camera from ZoneNet onto the PSL table. It gets its power from the overhead socket and connects via Cat5 to the Netgear switch in the PSL/IO rack.

You can connect to it on the Martian network by connecting to http://192.168.113.201:3037. Your computer must have Java working in the browser to make that work.

So far, this works on rossa, but not the other machines. It will take someone with Joe/Kiwamu level linux savvy to fix the java on there. I also don't know how to fix the host tables, so someone please add this camera to the list and give it a name.

As you can see from the image, it is  illuminating the PSL with IR LEDs. I've sent an email to the tech support to find out if we can disable the LEDs.

12221   Tue Jun 28 16:10:49 2016 PrafulUpdateGeneralBluebird Microphones

Found 1 out of 2 bluebird microphones in the 40m.

ELOG V3.1.3-