40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 227 of 341  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  12651   Wed Nov 30 14:54:01 2016 JohannesUpdateCDSSlow machine replacement

I was talking with Larry yesterday, and he suggested the rack-mounted supermicro machines SYS-5017A-EP (~$400) or SYS-5018A-FTN4 (~$600) that he uses for moving data around in LIGO. They have 2 gigabit ethernet ports and can thus function as modbus gateways, conveniently placed in the rack close to the slow DAQ/DIO chassis and running some local ubuntu or other distro (I think Aidan uses CentOS in the PSL lab). These only have atom processors, which would be sufficient for the slow machine replacement, but there are many more powerful models with sometimes subtle differences. If we motion towards a more complete GigECam coverage in the lab it could be better to kill two birds with one stone and get something a little faster that can do the video capture/processing, since these machines will be distributed more or less strategically around the lab. Just a thought, as I have currently no clear idea what resources are required for this or how much we're throwing at this GigECam upgrade.



I've attached a schematic for how we will connect the Acromag mosules to the slow channel I/O curently going to c1auxex. The following changes are made:

  • We are getting rid of the slow readbacks from the Anti-Image and Oplev boards, as Rana says they are unnnecessary.
  • The whitening switching for the QPD is currently done by a Contec "fast" binary I/O module, but can be managed by acromag instead. This alllows CAB_1Y9_34 to  be fed directly into the Acromag box since all of its connections can now be managed slow. 
  • There's no need to change the PD whitening scheme around (since the signals never get huge), so we can set those to always be on and then lose those Contec channels. This means all of the necessary pins on CAB_1Y9_10 can go to Acromag. 
  • All the other backplane cables go the the fast machines only. 



  11754   Wed Nov 11 22:50:39 2015 KojiConfigurationCDSSlow machine time&date

I was gazing at the log file for Autolocker script (/opt/rtcds/caltech/c1/scripts/MC/logs/AutoLocker.log )
and found quite old time stamps. e.g.

Old : C1:IOO-MC_VCO_GAIN             1991-08-08 14:36:28.889032 -3
New : C1:IOO-MC_VCO_GAIN             1991-08-08 14:36:36.705699 18
Old : C1:PSL-FSS_FASTGAIN            1991-08-09 19:05:39.972376 14
New : C1:PSL-FSS_FASTGAIN            1991-08-09 19:05:44.939043 18

It was found that the date/time setting of some of the slow machines (at least c1psl and c1iool0) is not correct.
I could not figure out how to fix it.

Question: Is this anything critical?

Another thing: While I was in c1iool0 I frequently saw the message like

c1iool0 > 0xc461f0 (CA event): Events lost, discard count was 514

Is this anything related to EPICS Freeze?

controls@nodus|~ > telnet c1psl.martian
Connected to c1psl.martian.
Escape character is '^]'.
c1psl > date
Aug 09, 1991 19:13:26.439024274
value = 32 = 0x20 = ' '
c1psl >
telnet> q
Connection closed.

controls@nodus|~ > telnet c1iool0.martian
Connected to c1iool0.martian.
Escape character is '^]'.

c1iool0 > date
Aug 08, 1991 14:44:39.755679528
value = 32 = 0x20 = ' '
c1iool0 > 0xc461f0 (CA event): Events lost, discard count was 514
Change MC VCO gain to -3.
0xc461f0 (CA event): Events lost, discard count was 423
Change MC VCO gain to 18.
Change boost gain to 1.
Change boost gain to 2.


  4201   Tue Jan 25 20:42:46 2011 OsamuUpdateGreen LockingSlow servo for green laser

I implemented a slow servo for green laser thermal control on c1scx.mdl. Ch6,7 of ADC and ch6 of DAC are assigned for this servo as below;


Ch6 of ADC: PDH error signal

CH7 of ADC: PZT feedback signal

CH6 of DAC: feedback signal to thermal of green laser


Note that old EPICS themal control cable is not hooked anymore.

I made a simple MEDM screen(...medm/c1scx/master/C1SCX_BCX_SLOW.adl) linked from GREEN medm screen (C1GCV.adl) on sitemap.

During this work, I noticed that some of the epics switch is not recovered by autoburt. What I noticed is filter switch of SUSPOS, SUSPIT, SUSYAW, SDSEN, and all coil output for ETMX.

I had no idea to fix them, probably Joe knows. I guess other suspensitons has the same problems.

  4202   Tue Jan 25 21:57:59 2011 KojiUpdateGreen LockingSlow servo for green laser

1. The dewhitening filter CH6 had no output. I disconnected the cable and put it to the monitor out of the AI filter.
So the dewhitening is not in the loop.

2. I have made a thermal control filter

BANK1: pole 0Hz, zero 1mHz / LF boost stage
BANK2: pole 1mHz, zero 30mHz / LPF stage
BANK3: pole 1Hz, zero 0.1Hz / phase compensation stage
Gain: 0.05

It seems working with the gain of 0.05. As the thermal is very strong, the output has less than 10.
This means the we are effectively only using ~4bit. We need external filter.

Note that output of 30000counts were about 3V at  CH6.

3. Measured End PZT feedback with and without the thermal control. The UGF seems to be 0.2Hz.
The suppression at 10mHz is ~100. This is so far OK.


I implemented a slow servo for green laser thermal control on c1scx.mdl. Ch6,7 of ADC and ch6 of DAC are assigned for this servo as below;


Ch6 of ADC: PDH error signal

CH7 of ADC: PZT feedback signal

CH6 of DAC: feedback signal to thermal of green laser


Note that old EPICS themal control cable is not hooked anymore.

I made a simple MEDM screen(...medm/c1scx/master/C1SCX_BCX_SLOW.adl) linked from GREEN medm screen (C1GCV.adl) on sitemap.

During this work, I noticed that some of the epics switch is not recovered by autoburt. What I noticed is filter switch of SUSPOS, SUSPIT, SUSYAW, SDSEN, and all coil output for ETMX.

I had no idea to fix them, probably Joe knows. I guess other suspensitons has the same problems.


Attachment 1: 110125_Xend_thermal.pdf
  665   Mon Jul 14 00:36:19 2008 JohnSummaryPSLSlow sweep of laser temp - PMC PZT response
John, Rana

Follow up to # 663

Top trace: C1: PSL-PMC_PZT

The only calibration I could find for the PMC PZT (LLO e-log Sep 3 2003 - 23 MHz/V) predicts 31V for an FSR. I did a rough calibration and got our FSR to be around 210 V. I assumed 713 MHz for an FSR and applied this calibration (~3.4 MHz/ V) to the PZT data.

In terms of volts per metre our PZT gives 2.54 nm/ V whereas the LLO PZT is 17.16 nm/ V.
Attachment 1: SlowTsweep.png
  15159   Mon Jan 27 18:16:30 2020 gautamConfigurationComputersSluggish megatron?

I've also been noticing that the IMC Autolocker scripts are running rather sluggishly on Megatron recently. Some evidence - on Feb 11 2019, the time between the mcup script starting and finishing is ~10 seconds (I don't post the raw log output here to keep the elog short). However, post upgrade, the mean time is more like ~45-50 seconds. Rana mentioned he didn't install any of the modern LIGO software tools post upgrade, so maybe we are using some ancient EPICS binaries. I suspect the cron job for the burt snapshot is also just timing out due to the high latency in channel access. Rana is doing the software install on the new rossa, and once he verifies things are working, we will try implementing the same solution on megatron. The machine is an old Sun Microsystems one, but the system diagnostics don't signal any CPU timeouts or memory overflows, so I'm thinking the problem is software related...


The burt snapshotting is still not so reliable - for whatever reason, the number of snapshot files that actually get written looks random. For example, the 14:19 backup today got all the snaps, but 15:19 did not. There are no obvious red flags in either the cron job logs or the autoburt log files. I also don't see any clues when I run the script in a shell. It'll be good if someone can take a look at this.

  15164   Tue Jan 28 15:39:04 2020 gautamConfigurationComputersSluggish megatron?

There were a bunch of medm processes stalled on megatron (connected with screenshot taking). To see if they were interfering with the other scripts, I killed all of the medm processes, and commented out the line in the crontab that runs the screenshots every 10 mins. Let's see if this improves stability.

  4844   Mon Jun 20 18:12:20 2011 NicoleUpdateSUSSmall Table Cleaned and Levelled


The small optical bench (next to the MC-2 Chamber and the tool box tower) has been cleared of the misc. object previously on it, cleaned, and leveled (after much calibration X___X).

PLEASE, PLEASE, PLEASE do NOT MOVE OR HIT THE TABLE! It was incredibly painful to level.

This is how leveling the table made me feel...


VERY SAD...so do not move please!

The shaker has already been moved to the table and the amplifier for my shaking experiment is located behind the table (not on the table, as to prevent scratching).



  5483   Tue Sep 20 16:31:24 2011 KeikoUpdateIOOSmall modulation depth

 Modulation resonator box is removed and the modulation depth is small right now.

I have broke the BNC connector on the modulation resonator box. The connector was attached by the screw inside very loosely and when we connect and disconnect the BNC cables from outside, extra force was applied to the cable inside and it was broke. It is being fix by Kiwamu and will be back in a bit.





  5484   Tue Sep 20 16:38:25 2011 KeikoUpdateIOOSmall modulation depth

Resonator box and the modulations are back now. But the modulation depth seems to be a bit smaller than yesterday, looking at the optical spectrum analyser.



 Modulation resonator box is removed and the modulation depth is small right now.

I have broke the BNC connector on the modulation resonator box. The connector was attached by the screw inside very loosely and when we connect and disconnect the BNC cables from outside, extra force was applied to the cable inside and it was broke. It is being fix by Kiwamu and will be back in a bit


  10942   Tue Jan 27 04:11:21 2015 JenneUpdateLSCSmall tweaks to the locking

[Jenne, Diego, EricQ]

We did a series of small things that may have helped with the locking, although we didn't actually get anywhere closer in CARM offset.

  • Removed the demodulation phase from the UGF servos.
    • We don't care about the phase value, just the magnitude.
    • Since we are using these through transitions between error signals, as well as with different filters coming on and off, the demodulation phase isn't constant, so the UGF servo is getting the wrong answer, and was throwing us out of lock.
    • The problems that Rana and I saw last time we had the sum of the sqrt were later discovered to be attributable to losing the peak in the noise, and hitting saturation limiters in the model, so not the fault of the sum of the squares.
    • I don't actually take the square root.  As Koji pointed out, the very next thing that happens to the signal is mag2dB, which is usually 20*log10(mag).  To compensate for the fact that I'm not taking the square root, I just use 10*log10(mag).  This removes one element of non-linearity, and leaves it at about the same number of square-ings as the complex division.
    • The excitation and measurement still happen after the multiplication.
    • The UGF screens will be updated tomorrow to reflect the change.
  • Added the new error signal rows to the LSC model's DAQ list.  So, now DARM_A_ERR and DARM_B_ERR are both acquired (and the same for CARM, MICH and PRCL).  This is to allow us to look at _DQ channels with dataviewer and DTT without having to clear the testpoints all the time.
    • We were running into too many channels being recorded, so we are not keeping the SRCL A & B signals right now.  Also, the CESAR signals that are no longer in use have been removed from the DAQ list.
  • Added a comb to the ASDC and POPDC signals, to remove the 60Hz harmonics from the MICH error signal.
    • The harmonics of the 60Hz line were dominating by more than an order of magnitude the RMS for the MICH control signal.  We couldn't afford too much phase at a few tens of Hz, so we do not notch out the original 60Hz line, although it isn't as big as, say, the 180Hz line.  So, I think that the notches are for the 2nd, 3rd, 4th and 5th order harmonics of 60Hz.  This significantly improved the RMS of the MICH output signal.
  • Lowered the MICH UGF slightly, from 48Hz to 41Hz. 
    • We wanted to go lower, to maybe 30Hz-ish, but we don't have the phase margin.  The roll mode notch is in the way, so we compromised at 41Hz.  With the comb mentioned above, the MICH control signal looks much more reasonable, and we're not injecting oodles of sensing noise into the BS.
    • Together with the comb, this ensures that we are not constantly railing the MICH output limiter, which lost us lock several times.
  • Increased the POPDC analog whitening gain from 0dB to 18dB.  We will certainly saturate POPDC when the carrier is resonant, but we were hoping to improve our SNR in our MICH error signal.  It helped noticeably, although we'll have to think about the fact that if it saturates while we're trying to acquire, the AS/POP composite signal won't be any good, and we'll kick the optics.  Also, we may have to lower the gain again as the carrier comes in to resonance.  Anyhow, something to think about.  Right now the gain is left at 18dB, and the dark offsets are set to match.
  • We may have been using the wrong side of the MICH offset, according to Q's plots.  We determined tonight that we want a (-) in the MICH gain, although the offset values can stay the same.  Even though we tried this, we didn't really get any farther in CARM offset reduction.
  • We took 2 sets of CARM and DARM loops.  They are both at 50% MICH offset, although I don't remember which sign the first one had.  The second one, at arm powers of 1.4, definitely had the new negative MICH gain. 
    • The first loop was taken at 50% MICH offset (don't remember which sign), and arm powers of about 1.15.
    • The second loop was taken at 50% MICH offset with negative gain, and arm powers of about 1.4.
    • While these numbers are not so different, maybe the first one was at roughly 300pm, and the second was at roughly 200pm, the loop shapes change dramatically.
    • The phase goes flat and we lose some of the phase margin.  Also, the magnitude is starting to get wiggly at lower frequencies.
    • See the transfer functions attached below.
  • While we were sitting at about arm powers of 1.4, with the 50% MICH offset with the negative sign in the gain, we set the REFL 11 demod phase.  It was 18.9deg (I don't remember from when), but we set it to 2.9deg to minimize the PRCL actuation in the Q-phase.  Oscillator was at 443Hz, about 10 counts. 
    • The coherence between the sqrtInvTrans signal and REFL11I looked pretty good from a few Hz to a few tens of Hz. 
    • It was late, so we decided to try transitioning over to REFL11I, and failed at the first very baby step.  So.  Ooops.
    • We should look more carefully at the TF between our current CARM signal and REFL11I.
    • We should also seriously consider using a normalized RF signal.  The SNR in the transmission PDs is just fine, although POPDC isn't a perfect choice at such high MICH offsets.
Attachment 1: CARM_27Jan2015_JCD.pdf
Attachment 2: DARM_27Jan2015.pdf
  10944   Tue Jan 27 15:45:26 2015 diegoUpdateLSCSmall tweaks to the locking

The UGF Servo medm page has been updated to reflect the last changes, namely the return of the sum of squares and the disappearance of Test3.


  9341   Mon Nov 4 23:11:00 2013 JenneUpdateLSCSmall updates to LSC screen

I made some small edits to the LSC screen. 

* When I added columns for the new AS110 PD, I had forgotten to make the Trigger matrix and Power Normalization matrix icons on the screen bigger, so we weren't seeing the last 2 columns in the overview screen.

* I added "show if not zero" oscillator icons to the Sensing Matrix part of the LSC overview screen, so that it's easier at a glance to see that there is an oscillator on.

  16775   Wed Apr 13 16:23:54 2022 Ian MacMillanUpdateGeneralSmell in 40m

[Ian, Paco, JC]

There is a strange smell in the 40m. It smells like a chemically burning smell maybe like a shorted component. I went around with the IR camera to see if anything was unusually hot but I didn't see anything. The smell seems to be concentrated at the vertex and down the y-arm

  9639   Fri Feb 14 12:39:02 2014 JenneUpdatesafetySmoke detector cleaned

Facilities just came by and cleaned the smoke detector that is above Steve's desk.  It's next to an air vent, so I guess it collects dust more than a "typical" smoke detector.

  4811   Mon Jun 13 18:40:08 2011 Jamie, JoeUpdateCDSSnags in the repair of LSC CDS

We've run into a problem with our attempts to get the LCS control back up and running.

As reported previously, the Dolphin fiber connection between c1lsc and c1sus appears to be dead.  Since we have no replacement fiber, the solution was to move the c1lsc machine in to the 1X4 rack, which would allow us to use one of the many available short Dolphin cables, and then use a long fiber PCIe extension cable to connect c1lsc to it's IO chassis.  However, the long PCIe extension cable we got from Downs does not appear to be working with our setup.  We tested the cable with c1sus, and it does not seem to work.

We've run out of options today.  Tomorrow we're going to head back to Downs to see if we can find a cable that at least works with the test-stand setup they have there.

  292   Fri Feb 1 15:04:54 2008 josephbConfigurationCamerasSnap with looping functionality available
New GiGE camera code is available in /cvs/cds/caltech/target/Prosilica/40mCode/. Currently only runs on Mafalda.

Snap has expanded functionality to continuously loop infinitely or for a maximum number of images set by the user. File names generated with the loop option have the current Unix time and .tiff appended to them. So -f './test' will produce tiff files with format "test1234567.tiff". The -l option sets the number of seconds between images.

"./Snap -l 5 -i -f './test' " will cause the program to infinitely loop, saving images every 5 seconds. Using "-m 10" instead of "-i" will take a series of 10 images every 5 seconds (so taking a total of 50 seconds to run).

It also now defaults to 16-bit (in reality only 10 bit) output instead of 8 bit output. You can select between the two with -F 'Mono8' or -F 'Mono16'.

Use --help for a full list of options.

Note that if you ctrl-c out of the loop, you may need to run ./ResetCamera (or whatever the IP is - use ./ListCameras to determine IP if necessary) in order to reset the camera because it doesn't close out elegantly at the moment.
  1206   Mon Dec 29 21:38:57 2008 YoichiUpdateComputersSnapshots of MEDM screens
I wrote scripts to take snapshots of MEDM screens in the background.
These scripts work even on a computer without a physical display attached.
You don't need to have X running.
So now the scripts run on nodus every 5 minutes from cron.
The screen shots are saved in /cvs/cds/caltech/statScreen/images/

There is a wiki page for the scripts.

Someone has to make a nice web page summarizing the captured images.
  1221   Fri Jan 9 17:30:10 2009 KakeruUpdateComputersSnapshots of MEDM screens
I wrote a web page which shows snapshots of MEDM screens generated by Yoich's script (e-log #1206).
This page refreshes itself every 5 minutes automatically.

The .html file is generated by /cvs/cds/caltech/statScreen/bin/genHtml.pl
This script generates the .html file contains snapshots listed on /cvs/cds/caltech/statScreen/etc/medmScreens.txt every 5 minutes with cron.
When you wont to display other screens, please edit this .txt file and wait 5 minutes!

To make thumbnails, I wrote /cvs/cds/caltech/statScreen/bin/genThumbnail.pl
This script reads /cvs/cds/caltech/statScreen/etc/medmScreens.txt, too.
(Sometimes, it makes thumbnails with larger storage...)

I wrote scripts to take snapshots of MEDM screens in the background.
These scripts work even on a computer without a physical display attached.
You don't need to have X running.
So now the scripts run on nodus every 5 minutes from cron.
The screen shots are saved in /cvs/cds/caltech/statScreen/images/

There is a wiki page for the scripts.

Someone has to make a nice web page summarizing the captured images.
  13072   Mon Jun 19 18:32:18 2017 jigyasaUpdateComputer Scripts / ProgramsSoftware Installation for image analysis

The IRAF software from the National Optical Astronomy Observatory has been installed locally on Donatella(for testing) following the instructions listed here at http://www.astronomy.ohio-state.edu/~khan/iraf/iraf_step_by_step_installation_64bit
This is a step towards "aperture photometry" and would help identify point scatterers in the images of the test masses.

I will be testing this software, in particular, the use of DAOPHOT and if it seems to work out, we may install it on the shared directory.
Hope this isn't an inconvenience.



  25   Mon Oct 29 11:07:22 2007 waldmanSoftware InstallationOMCSoftware install on OMS
[Alex, Sam]

We spent a little time this morning working on OMS and getting things restarted. A few changes were made. 1) We put openmotif on OMS so that the burtrb doesn't throw that crappy libXm any more. 2) We upgraded OMS to a 32 kHz sampling rate from 2 kHz. All the filters will have to be changed. We also added a PDH filter path to maybe feedback PDH signals cuz that will be cool. Maybe someday I will write up the very cool channel adding procedure.
  12433   Tue Aug 23 17:05:20 2016 PrafulUpdateElectronicsSoldered Circuit Working

I remade another soldered circuit, adding extra 100uF electrolytic bypass capacitors at the input and output of the voltage regulator and ensuring that every grounded component now has its own path to ground rather than going through other elements. This circuit now seems to be working just like the solderless circuit. Attached is the transfer function of the soldered circuit, which matches with the result from the solderless circuit.




Here are both on the same figure- they are about overlapping but are slightly different if you zoom in enough.


I have also attached a new version of the circuit schematic to reflect the changes and to make the physical layout more clear.


My next step for these last few days this summer will be designing a PCB using Altium. I've emailed Varun about how to use Altium on the iMac but he hasn't responded. If anyone else knows how to use the software, please let me know.

Attachment 2: soldered_transfer_function.png
Attachment 3: soldered_transfer_function.png
Attachment 5: solderless_transfer_function.png
Attachment 6: both_transfer.png
Attachment 8: both_transfer.png
Attachment 10: simple_ampv2.pdf
  15201   Mon Feb 10 09:40:54 2020 Larry WallaceSummaryGeneralSolidWorks Computer Upgrade and Printer repair

On February 5, 2020, the Dell engineering workstation located in the 40M lab, was replaced with a newer Engineering workstation, per a request from Koji . The new workstation should perform a good deal better over the older unit. It has more cores, more memory and a better video card. Since this unit is being used by the 40M group, the Comsol s/w pkg. was also installed on the unit.

During the computer swap, Koji had a problem with a print job and it was discovered the bottom tray of the HP5550 printer was broken. The broken tray was replaced from another unit that was being disposed of.

  13561   Fri Jan 19 20:59:07 2018 Udit KhandelwalUpdateGeneralSolidworks Rendering

Rendered the SOS assembly (D960001) with correct materials and all and it looks very nice. Will extend this to the building cad later.

  14813   Thu Jul 25 20:08:36 2019 gautamUpdateComputersSolidworks machine

I brought one CPU (Dell T3500) and one 28" monitor from Mike Pedraza's office in Downs to the 40m. It is on Steve's desk right now, pending setup. The machine already has Solidworks and Altium installed on it, so we can set it up at our leisure. The login credentials are pasted on the CPU with a post-it should anyone wish to set it up.

  2003   Fri Sep 25 17:51:51 2009 KojiUpdateMOPASolved (Re: Total MOPA power is constant, but the NPRO's power has decreased after last night's activities?)

Jenne, Koji

The cause of the decrease was found and the problem was solved. We found this entry, which says

Yoich> We opened the MOPA box and installed a mirror to direct a picked off NPRO beam to the outside of the box through an unused hole.
Yoich> We set up a lens and a PD outside of the MOPA box to receive this beam. The output from the PD is connected to the 126MON cable.

We went to the PSL table and found the dc power cable for 126MOPA_AMPMON was clipping the 126MON beam.
We also made a cable stay with a pole and a cable tie.

After the work, 126MON went up to 161 which was the value we saw last night.

We also found that the cause of the AMPMON signal change by the DAQ connection, mentioned in this entry:

Jenne> 6.  We teed off of the AMPMON photodiode so that we could see the DC values on a DMM. 
Jenne> When we used a T to connect both the DMM and the regular DAQ cable, the DMM read
Jenne> a value a factor of 2 smaller than when the DMM was connected directly to the PD.

We found a 30dB attenuator is connected after the PD. It explains missing factor of 2.


[Koji, Jenne]

Steve pointed this out to me today, and Koji and I just took a look at it together:  The total power coming out of the MOPA box is constant, about 2.7W.  However, the NPRO power (as measured by 126MOPA_126MON) has decreased from where we left it last night.  It's an exponential decay, and Koji and I aren't sure what is causing it.  This may be some misalignment on the PD which actually measures 126MON or something though, because 126MOPA_LMON, which measures the NPRO power inside the NPRO box (that's how it looks on the MEDM screen at least...) has stayed constant.  I'm hesitant to be sure that it's a misalignment issue since the decay is gradual, rather than a jump. 

Koji and I are going to keep an eye on the 126MON value.  Perhaps on Monday we'll take a look at maybe aligning the beam onto this PD, and look at the impedance of both this PD, and the AMPMON PD to see why the reading on the DMM changed last night when we had the DAQ cable T-ed in, and not T-ed in. 


  15232   Thu Feb 27 17:59:02 2020 gautamUpdateLSCSome AO thoughts

While my checks of the AO signal path have thrown up some unanswered questions, I don't think there's any evidence in those measurements to suggest the AO crossover can't be realized. Thinking about it today though - I was wondering if it could be that the IN1 gain slider of the CM board is configured optimally. Looking back at some data, when the ALS CARM offset is zeroed, the CM_SLOW digitized data has a peak-to-peak range of ~200 cts. This is paltry. One possibility is that as I am upping the AO path gain, I'm simply injecting the electronics noise of the CM board into the IMC error point. I'd say it is safe to up the IN2 gain by 20dB to -12 dB, in which case the peak-to-peak would be ~2000 cts, still only 10% of the ADC range. It'll be straightforward to re-scale the CARM_B loop gain to account for this. Let's see if this helps.

I'd also like to measure the spectrum of the REFL11_I signal in a few different states. I think I should be able to do this using the OUT2 of the CM servo board. These are the things to try tonight:

  • Try CARM RF handoff with CM_SLOW gain starting at -12dB instead of -32dB.
  • Measure spectrum of REFL11_I when it is in the linear range.
  9784   Thu Apr 3 18:55:10 2014 ericqSummaryLSCSome CARM related modeling

 The other day, Jenne and I were comparing my MIST simulation to her Optickle simulation for the CARM transfer functions I posted some days ago. She told me that the arms are not exactly where they should be for the whole "PRC length tuning to account for sideband reflection phase off resonant cavity" deal. 

Specifically, as in the wiki (but with newer modulation frequencies), I calculated the ideal arm length to be 37.795 m some time ago, when doing PRC length simulations, and Jenne has told me that the X arm is more like 37.6m, and Y is 37.9. So, I updated my simulations, and found the following:

This does weird things to the f2 sideband buildup on resonance in the PRFPMI configuration:

asIsPRCRes.pdf idealPRCRes.pdf

(POP is way huger than than the TR's, because the POP pd's are artificially "inside" the cavity, whereas TRX/Y is actually transmitted through an ETM)

This is not necessarily directly something to worry about, but I think the following may be. It looks like this arm length mismatch actually causes the PRCL demodulation phase in REFL 165 to change dramatically with the CARM offset. (REFL33 seems fine, though. 5 degrees causes less than a 1% effective gain change.) 


My simulations don't include any signal recycling yet, so I don't have anything to show if there is a similar effect for SRCL, but it wouldn't surprise me... 


  15017   Wed Nov 6 19:26:57 2019 gautamUpdatePSLSome PSL cable admin

Koji and I taked about cleaning up some of the flaky cable situation on the PSL table a while ago. The changes were implemented and are documented in Attachment #1. Now the Pomona box between the Thorlabs HV Driver and the NPRO head is sitting on the PSL table (sandwiched between some teflon pieces I found in cabinet S4 along the south arm), and the cables between these two devices are better strain relieved. I turned off the Thorlabs HV supply while working on the PMC table. The IMC could be locked after this work. Probably won't solve the long standing FSS mysteries but probably can't hurt.

Unrelated to this work: I also removed a Bias tee that was just hanging out on top of the FSS electronics, which was used for the modeSpec project.

Attachment 1: PSLcableAdmin.jpg
  4034   Thu Dec 9 01:54:15 2010 JenneUpdateElectronicsSome Refl 11 fixes

The Backstory:

Kevin was working on characterizing all of our RF photodiodes for the upgrade, and he discovered that REFL11 didn't work, as described in elog 3890.  Rana was working on fixing it, but then he went off to Japan.

Today's Activities:

I visually inspected the components inside the RF cage on the REFL 11 circuit board inside the PD.  Most of them were okay, but the connection between L5 and C33 (the big tunable inductor and the next capacitor in the path) was totally flaky.  the leg of the inductor had been soldered directly to the trace on the PCB, and the inductor was a little bit tipped over, and pulling the trace off the board.  I wiggled it a little while trying to see what was going on, and the trace broke.  Since there is nothing going on between L5 and C33, just the trace, I used a piece of resistor lead to attach the two.  The connection now seems very robust.  I'm a little worried about the connection between the inductor and the board on the other side, but I can't see it since it's under the inductor itself.

Also, the soldering of L4 (a standard surface mount component type body) to the board seemed totally shoddy.  I was desoldering the first side, and the whole inductor popped off.  It was clear that the inductor was making a physical connection to the board, but not a nice solid electrical connection.  So I resoldered it on.  (On Alberto's schematics, it is listed as a 633nH inductor.  I can't find any of this value, so I just put the same one back on.  The best I could do to confirm the component was still okay was measure its resistance, and compare that to a similar inductor of a similar value.  It seemed okay.)

After that I powered up the PD, and took an electrical transfer function, just to have a look-see.  It seems kind of okay, although the resonance seems to be closer to 13MHz than 11MHz. 

Since we would like to remove the capacitor that is in parallel with the diode itself, which will then change all of the resonant conditions on other components, I didn't worry too much about the resonant peak for tonight.  We're going to have to look in on this though.

Also, I'm leaving the optical check-out for Kevin, so he will let us know if I magically fixed the PD, or if it needs some more work.

Photos of the circuit board (mostly Alberto's mods) before and after I fitzed with it are on Picasa

The Future:

More testing. Probably more fixing.


  10656   Fri Oct 31 02:19:37 2014 ericqUpdateLSCSome SRMI progress

Earlier today, I did some simulations that suggested that PRC lengths on the order of a cm from our current estimated one could result in degenerate PRCL and MICH signals in REFL165 at 3nm CARM offset. I attempted more demod-angle derived cavity PRC length measurements with REFL11 and REFL55, but they weren't consistent with each other...

In any case, adding dual recycling, even with a SRC length off by 1cm in either direction, doesn't seem to exhibit the same possibility, so I spent some time tonight seeing if I could make any progress towards DRMI locking. 

I was able to lock SRY using AS55 in a very similar manner to PRY, after adjusting the AS55 demod angle to get the error signal entirely in I. I used this configuration to align the SRM to the previously aligned BS and ITMY. Oddly, I was not able to do anything with SRX as I had hoped; the error signal looks very strange, looking more like abs(error signal). 

I then was able to lock the SRMI on AS55 I & Q, the settings have been saved in the IFO configure screen.  I've used AS55Q for PRMI locking with a gain of -0.2, so I started with that; the final gain ended up being -0.6. PRMI/PRY gain for prcl is something like 0.01, so since I used a gain of 2 for locking SRX, I started the SRCL gain around 0.02, the final gain ended up being -0.03. I basically just guessed a sign for AS110 triggering. Once I lucked upon a rough lock, I excited the PRM to tune the AS55 angle a few degrees; it was luckily quite close already from the SRY adjustment. AS110 needed a bigger adjustment to get the power into I. (AS55: -40.25->-82.25, AS110: 145->58, but I put AS55 back for PRMI)

I briefly tried locking the DRMI, but I was really just shooting in the dark. I went back and measured various sensing amplitudes/angles in SRMI and PRMI configurations; I'm hoping that I may be able to simulate the right gains/angles for eventual DRMI locking.

  9654   Wed Feb 19 11:00:16 2014 ericqUpdateLSCSome Simulation Efforts


 As Koji measured the other day: MICH and PRCL seem very degenerate in the 3f REFL PDs. 

I'm using this as a motivation to do some simulation in MIST and try to understand the best way to implement the 3F locking scheme. Hopefully my thinking below isn't nonsense...

First, I modeled the PRC with no arm cavities and the estimated cavity length I got with the PRM kick measurement, and looked at the REFL sensing matrix.


This agrees with the observed degeneracy. I then modeled the case of the PRC length that gives coincident SB resonance, again with no arm cavities.


Now there is good separation in REFL165. (REFL33 still looks pretty degenerate, however). This raised the question, "What does the angle between MICH and PRCL in REFL165 do as a function of macroscopic PRC length?" 


  • We see ~90 degrees at coincident resonance
  • Shortening the cavity, which we did to account for the arms, quickly shrinks the angle
  • Presuming we moved to make the cavity 4cm shorter implies we had ~45 degrees between MICH and PRCL in REFL165 before the move. (Is this consistent with earlier observations?)

To me, this implies that locking the PRC on 3F from scratch won't be simple. However, the whole point of the PRC length choice is to have coincident SB resonance when the arms are resonating.

So: even if we're not spot on, we should be relatively close to the PRC length where having arms resonant gives us simultaneously resonant upper and lower sidebands, where MICH and PRCL should be orthogonal-ish. I.e. building up a little bit of IR power in the arms may start to break the degeneracy, perhaps allowing us to switch from 1F to 3F locking, and then continue reducing the CARM offset. 

So, I ultimately want to model the effect of arm power buildup on the angle between MICH and PRCL in the 3f PDs. This is what I'm currently working on. 

So far, I have reproduced some of the RC modeling results on the wiki to make sure I model the arms correctly. (I get 37.7949 m as the ideal arm length for a modulation freq of 11.066134 MHz vs. 37.7974m for 11.065399 MHz as stated on the wiki). Next, I will confirm the desired PRC length that accounts for the arms, and then look at the MICH vs PRCL angle in the REFL PDs as a function of arm power or detuning. 


  9656   Wed Feb 19 14:14:46 2014 ericqUpdateLSCSome Simulation Efforts


Koji noted oddities in the sensing matrix results I had gotten; namely that the plots showed REFL33 not changing at all, when we know for a fact that this should not be the case. 

Gabriele lent his eyes to my code, and came up with the idea that the modulation depths I was using were maybe not ideal (.1 for both 11 and 55). This affects REFL33 in that it is not simply Carrier * 33Mhz + 11Mhz * -22Mhz but also 22MHz * 55MHz, etc. 

I got more realistic values from Jenne (0.19 for 11MHz and .26 for 55Mhz) and re-ran the code, with more realistic results. The behavior for 165 has remained the same, but the other signals are more well behaved. 

Moral of the story: the modulation depths affect the 3f signals in a complicated way.






  9657   Wed Feb 19 16:42:08 2014 ericqUpdateLSCSome Simulation Efforts

Disregard previous ELOGs, I had the PRC locked on carrier 

Locked on the sideband, the MICH / PRCL angle is much less sensitive to the PRC length, and shouldn't in fact be as degenerate as we've seen in reality. 


So, my simulations no longer provide any reason for the 3F signals to be so degenerate. 

  3249   Tue Jul 20 11:49:31 2010 JenneUpdateSUSSome Suspensions not damping

[Jenne, Koji]

I moseyed into the control room this morning, to find ITMX and ITMY both with their watchdogs tripped.  ITMY (new convention) wouldn't damp.  Koji discovered that there was a sign flip in 2 of the sensors.  A set of reboots of c1susvme1&2 fixed the problem. 

A side note:  For the ETMs, the OSEM sensor readouts are gigantic (~20,000), whereas for the similar channels on all other optics, the readouts are on the order of 1.  After some looking around, it seems that this is just the way things have been (for at least 100 days), and the filters in the SUSPOS and other SUS filter banks have a high pass filter to take care of this.  It's weird, but it seems to be the way it is, and the ETMs damp, so it's all good.

  14397   Fri Jan 11 16:38:57 2019 gautamUpdateGeneralSome alignment checks

The pumpdown seems to be progressing smoothly, so I think we are going to stick with the plan decided on Wednesday, and vent the IFO on Monday at 8am. I decided to do some checks of the IFO alignment.

I turned on the PSL again (so goggles are advisable again inside the VEA until this work is done), re-locked the PMC, and opened the PSL shutter into the vacuum (still low power 100 mW beam going into vacuum). The IMC alignment required minor tweaking, but I recovered ~1300 cts transmission which is what it was --> so we didn't macroscopically change the input pointing into the IMC while working on the IOO table.

Centering the ITMY oplev spot, there is a spot on the AS camera roughly centered on the control room monitor, so the TT pointing must also be pretty close.

Then I centered the ITMY oplev spot to check how well-aligned or otherwise the Michelson was - the BS has no Oplev so there was considerable angular motion of the Michelson spot, but it looked like on average, it was swinging around through a well aligned place. I saved the slow bias voltages for the ITMs and BS in this config.

Then I re-aligned ETMX and checked the green transmission - it was okay, ~0.3, and I was able to increase it to ~0.4 using the EX green PZT mirrors. So far so good.

Finally, I tried to lock the X-arm on IR - after zeroing the offsets on the transmission QPD, there seems to be a few flashes as the cavity swings through resonances, but no discernible PDH error signal. Moreover the input pointing of the IR into the X arm is controlled by the BS which is swinging around all over the place right now, so perhaps locking is hopeless, but the overall alignment of the IFO seems not too bad. Once ETMY is cleaned and put back in place, perhaps the Y arm can be locked.

I shuttered the PSL and inserted a manual beam block, and also turned off the EX laser so that we can vent on Monday without laser goggles.

*Not directly related to this work: we still have to implement the vacuum interlock condition that closes the PSL shutter in the event of a vacuum failure. It's probably fine now while the PSL power is attenuated, but once we have the high power beam going in, it'd be a good to revert to the old standard.

Attachment 1: pd82.png
Attachment 2: LSC_X.png
  15620   Thu Oct 8 15:08:25 2020 gautamUpdateGeneralSome boxes moved from 40m entry hallway
  • UPS batteries
  • 2x HEPA filters
  • VWR chemicals (methanol)

These boxes were moved from the 40m hallway to the inside of the VEA so that we have some space to walk around. You can find some pictures here.

  3172   Wed Jul 7 22:22:49 2010 JenneUpdateComputersSome channels not being recorded!!!

[Rana, Jenne]

We discovered to our great dismay that several important channels (namely C1:IOO-MC_L, but also everything on c1susvme2) are not being recorded, and haven't been since May 17th.  This corresponds to the same day that some other upgrade computers were installed.  Coincidence?

We've rebooted pretty much every FE computer and the FrameBuilder and DAQ_CONTROL approximately 18 times each (plus or minus some number).  No matter what we do, or what channels we comment out of the C1SUS2.ini file, we get a Status on the DAQ_Detail screen for c1susvme2 of 0x1000.  Except sometimes it is 0x2000.  Anyhow, it's bad, and we can't make it good again. 

I have emailed Joe about fixing this (with some assistance from Alberto, since we all know how much he likes doing the Nuclear Reboot option for the computers :)

  3176   Thu Jul 8 14:11:16 2010 josephbUpdateComputersSome channels not being recorded!!!

This has been fixed, thanks to some help from Alex. It doesn't correspond to new computers being put in, but rather corresponds to a dcu_id change I had made in the new LSC model.

The fundamental problem is way back when I built the new LSC model using "lsc" as the name instead of something like "tst", I forgot to go to the current frame builder master file (/cvs/cds/caltech/chans/daq/master) and comment out the C1LSC.ini line. Initially there was no conflict with c1susvme, because the initially was dcu_id 13. The dcu_id was eventually changed to 10 from 13 , and thats when it conflicted with the c1susvme2 dcu_id which was also 10. I checked it against wiki edits to my dcu_id list page and I apparently updated the list on May 20th when it changed from 13 to 10, so the time frame fits.  Apparently it was previously conflicting with C0GDS.ini or C1EXC.ini, which both seem to have dcu_id = 13 set, although the C1EXC file is all commented out. The C0GDS.ini file seems to be LSC and ASC test points only.

The solution was to comment out the C1LSC.ini file line in the /cvs/cds/caltech/chans/daq/master file and restart the framebuilder with the fixed file.


[Rana, Jenne]

We discovered to our great dismay that several important channels (namely C1:IOO-MC_L, but also everything on c1susvme2) are not being recorded, and haven't been since May 17th.  This corresponds to the same day that some other upgrade computers were installed.  Coincidence?

We've rebooted pretty much every FE computer and the FrameBuilder and DAQ_CONTROL approximately 18 times each (plus or minus some number).  No matter what we do, or what channels we comment out of the C1SUS2.ini file, we get a Status on the DAQ_Detail screen for c1susvme2 of 0x1000.  Except sometimes it is 0x2000.  Anyhow, it's bad, and we can't make it good again. 

I have emailed Joe about fixing this (with some assistance from Alberto, since we all know how much he likes doing the Nuclear Reboot option for the computers :)


  3179   Thu Jul 8 15:43:58 2010 ranaUpdateComputersSome channels not being recorded!!!


This has been fixed, thanks to some help from Alex. It doesn't correspond to new computers being put in, but rather corresponds to a dcu_id change I had made in the new LSC model.

 Just as I expected, since these hunuman didn't actually check MC_L after doing this stuff, MC_L was only recording ZERO. Joe and I reset and restarted c1susmve2 and then

verified (for real this time) that the channel was visible in both the Dataviewer real time display as well as in the trend.


The lesson here is that you NEVER trust that the problem has been fixed until you check for yourself. Also, we must always

specify a very precise test that must be used when we ask for help debugging some complicated software problem.


  314   Wed Feb 13 11:41:00 2008 AlbertoUpdateElectronicsSome characterization of the RF Monitor Box (StocMon)
I'm attaching a table with some measurements and the power spectrum from the pd to help evaluate the numbers.

The box output ranges from 0.5V to 2.1V. The coefficient between power and voltage is negative so higher voltage means lower power.

The red numbers are the outputs from each channel at their resonant frequencies. As one can see these are not very well centered on the dynamic range of the power detectors.

The cross coupling seems to be not a problem.

Even if the 166 filter, which handles the smallest of the frequencies and is also the most lossy (for construction reason), mounts a preamplifier, the output is still rather small. this explain also the high bias due to the noise amplification at the maximum power (13dB). A better insertion loss either remaking the filter or re-tuning that one would simplify many problems, i.e. there is not much room in the metal pomona box to fit the amplifier. I might want to consider, after everything else is ready and if I have time before leaving next week, to work on a new 166 filter.
Attachment 1: CircuitCharacterization.png
Attachment 2: alberto.spectrum3.png
  9613   Fri Feb 7 17:52:41 2014 KojiSummaryGeneralSome cleaning up
  • Adjusted the PMC alignment
  • Adjusted the IMC length offsets for the MC servo and the FSS servo
  • Adjusted the MC alignment. Ran /opt/rtcds/caltech/c1/scripts/MC/WFS/WFS_FilterBank_offsets
  • The Yarm servo was oscillating. Reduced the servo gain from 0.2 to 0.08.
  • AS Camera & AS port alignment was adjusted. Now the spot is at the center of the AS camera.
  • Cleaned up the ASC offsets on the suspensions (i.e. C1:SUS-***_(PIT|YAW)_OFFSET) by replacing them by the BIAS adjustment.
  • Saved the alignment values
  • Locked the PRMI with SB with REFL55I for PRCL and AS55Q for MICH
  • Aligned the PRM, then checked the alignment of the REFL PDs
  • The best POP110I was 500cnt.
  • Found REFL165 output was disconnected. It is now restored.
  • Used the LSC lockins to figure out the demod phases and the signal amplitudes (relative)

PRCL: 100cnt -> PRM 567.01Hz

Signal in demod Q ch were minimized

REFL11I -19.2deg demod I, Lockin I out (C1:CAL-SENSMAT_PRCL_REFL11_I_I_OUTPUT) 12.6 cnt
REFL33I +130.4deg 1.70cnt
REFL55I +17.0deg 2.30cnt
REFL165I -160.5deg 27.8cnt

MICH: 1000cnt -> ITMX(-1) & (ITMY +1.015 => Minimized the signal in REFL11I to obtain pure MICH)

REFL11I   +0.0     REFL11Q   +0.119
REFL33I   +0.023 REFL33Q   -0.012
REFL55I   +0.023 REFL55Q   -0.113
REFL165I +0.68   REFL165Q +0.038

It seems that REFL165 has almost completely degenerated PRCL and MICH.

  • Try to replace ITMX/Y with BS (+0.16) / PRM (-0.084)

 ITMX(-1)/ITMY(+1.015) actuation was cancelled by BS (+0.16). This introduces PRCL in REFL11I. This was cancelled by PRM (-0.084)


REFL11I   +0.0     REFL11Q   +0.13
REFL33I   -0.012  REFL33Q   0.025
REFL55I   +0.041 REFL55Q   -0.45
REFL165I +0.69   REFL165Q +/-0.02

Again, It seems that REFL165 has almost completely degenerated PRCL and MICH.

Locking info:

[Signal source] REFL11I (-19.2deg) x 0.16, OR REFL33I (+130.4deg) x 2.0, OR REFL55I (+17.0deg) x1.0, OR REFL165I (-160.5deg) x0.05
[Trigger] POP110I(-81deg) 100/10, FM trigger 35/2, delay 0.5sec FM2/3/6/9
[Servo] FM4/5 always on. G=-0.02, Limitter ON
[Output] PRM x+1.00

[Signal source] AS55Q (-5.5deg) x 1, OR REFL11Q x 0.25, OR REFL55Q x-0.06
[Trigger] POP110I 100/10, FM trigger 35/2, delay 5sec FM2/3/9
[Servo] FM4/5 always on. G=-10, Limitter ON
[Output] ITMX -1.0 / ITMY +1.0 (or +1.015), OR PRM -0.084 / BS +0.16



  3221   Wed Jul 14 18:09:50 2010 josephb, razibUpdatePhase CameraSome cleanup behind 1Y2 rack of phasecamera electronics

We made an attempt at cleaning up the phase camera setup electronics.

We have moved a portion of the electronics onto the SP table (specifically the mixer, splitters, amplifiers, and associated power).  We put away a large number of cables which were unneeded, both BNC and power cables. The Innolight Mephisto power supply and one signal generator are still behind 1Y2 on top of a non-functioning VME crate.  The second VME crate was put along the south arm where two other VME crates already were.  We placed a fair number of BNC cables and power cords back on their cable racks or approriate storage space, so the rats nests of cables has been reduced.

We moved one power strip from plugging in beyind 1Y1, to the far side of the SP table (closer to the 1Y3 rack), and also found and plugged in another power strip (also on the far side of the SP table) and placed this underneath the SP table to be able to power the signal generator and Innolight Mephisto laser (its not plugged in currently, but we'd like to do so next week).


  1404   Sun Mar 15 21:50:29 2009 Kakeru, Kiwamu, OsamuUpdateComputersSome computers are rebooted

We found c1lsc, c1iscex, c1iscey, c1susvme, c1asc and c1sosvme are dead.
We  turned off all watchdogs and turned off all lock of suspensions.
Then, I tried to reboot these machines from terminal, but I couldn't login to all of these machines.

So, we turned off and on key switches of these machines physically, and login to them to run startup scripts.

Then we turned on all watchdogs and restored all IFO.

Now they look like they are working fine.

  6105   Mon Dec 12 11:34:40 2011 Leo SingerSummaryGeneralSome design parameters for a Stewart platform

At the suggestion of Rana and Koji, I have worked out some design parameters for a Stewart platform to be used as a vibration isolation device or as a platform for characterization of suspensions.  I have made some initial guesses about the following design requirements:

  • linear travel: 40 microns peak to peak (based on SOS design requirements in LIGO-T950011)
  • angular travel: 3 mrad peak to peak (based on SOS design requirements in LIGO-T950011)
  • payload mass: 5 kg (wild guess of mass of loaded SOS)
  • payload moment of inertia: 0.01 kg m^2 (wild guess)
  • bandwidth: 500 Hz (suggestion of Rana and Koji: ~kHz)

From these assumptions, I have worked out:

  • peak actuator force: 0.88 kN
  • minimum radius of top platform: 15 cm
  • minimum radius of bottom platform: 30 cm
  • minimum height: 26 cm

The combination of high force, high speed, and ~micron travel limits seems to point to piezoelectric actuators.  PI's model P-225.80 would meet the peak push-pull force requirement, but I have not yet determined if it would meet the bandwidth requirement.  Apparently, typical piezoelectric actuators can exert a greater push force than pull force; wonder if one could use an actuator with a smaller force range than the P-225.80 if the actuator is biased by compression.  (Is this what is meant by a "preloaded" actuator?) 

I have attached a PDF explaining how I worked out the actuator force and platform dimensions.  (I'll try to dice up this PDF and put the contents in the Wiki.)  I also have a plant model in MATLAB with which I have been playing around with control schemes, but I don't think that this is ready to show yet.

Here are some tasks that still remain to be done for this preliminary case study:

  • select sensing technologies: integrated linear encoders and/or strain meters, inertial sensing, optical levers, etc.
  • study joints: Koji and Rana suggest flexures; I need to propose the joint geometry and material
  • study internal modes of the platforms and actuators themselves
  • build noise budget

I'd like to ask for input principally on:

  • appropriateness of my design assumptions
  • piezo actuators currently in use in the lab

 Edit: I also added a Mathematica notebook with the inverse kinematics (mapping from platform state to leg lengths) of the platform. 






Attachment 1: stewart.pdf
stewart.pdf stewart.pdf stewart.pdf stewart.pdf stewart.pdf stewart.pdf stewart.pdf
Attachment 2: stewart.nb
(* Content-type: application/vnd.wolfram.mathematica *)

(*** Wolfram Notebook File ***)
(* http://www.wolfram.com/nb *)

(* CreatedBy='Mathematica 8.0' *)

(*CacheID: 234*)
(* Internal cache information:
... 377 more lines ...
  9742   Fri Mar 21 01:54:32 2014 ericqUpdateLSCSome early CARM modeling

 I've been getting a simulation going with the eventual goal of simulating CESAR-type signals for CARM. So for I've only been using MIST, though I'm still thinking about what to do for a fully time domain approach. (For example, maybe a mixture of simulink and analytical equations? We'll see how painful that gets...)

Anyways, with the parameters I have for the 40m, I've set up a simulation, where I can do things like a "static" CARM scan.

(i.e. PRMI perfectly locked. Ask what different PDs see if the arms were just statically sitting at some CARM offset)


PDH signals are there in the REFL diodes. The coupled line width here looks smaller than the ~40pm number I've heard before, so I should check my parameters. (Likely culprit, I'm using nominal R and T for the arm cavities)

I've also done the slightly more sophisticated thing of looking at the transfer function from CARM motion to different PDs, at different CARM offsets. For TRX and REFLDC, these seem to match up qualitatively to some plots that Kiwamu has done for aLIGO, with frequencies shifted by the relative arm length factor of 100. (Q's left, K's right, Y-axis on mine are W/m with 1W input the IFO)



carm2reflDC.pdf CARM_TFs_REFLDC.pdf


We can also look at the PDH diodes (revised from my initial post. Had an error in my code): 



That's where I've gotten so far!


  15347   Tue May 26 01:58:57 2020 gautamUpdateElectronicsSome electronics thoughts

A big factor in how much IFO locking activities can take place is how cooperative the IMC is.

Since the c1psl upgrade, the IMC duty cycle has definitely deteriorated. I took a measurement of the dark noise at the IMC error point with 1 Hz FFT binwidth, with all electrical connections to the IMC servo board except the Acromag and Eurocrate power disconnected. I was horrified at the prominence of 60 Hz harmonics - see Attachment #1. In the past, this kind of feature has been indicative of some error in the measurement technique - but I confirmed that the lines remain even if I unplug the GPIB box, and all combinations of floating/grounded inputs that I tried. We know for sure that there is some excess noise imprinted on the laser light post upgrade. While these lines almost certainly are not responsible for the PCdrive RMS going bonkers, surely this kind of electrical situation isn't good?

Attachment #2 shows the same information translated to frequency noise units, taking into account the complementary sensitivity function, L/(1+L) - the sum contribution of the 60 Hz peaks to the RMS is ~11.5% of the total over the entire band (c.f. 1.7 % that is expected if the noise at multiples of 60 Hz was approximately equal to the surrounding noise levels). Moreover, the measured RMS is 55 times higher than a LISO model. 

How can this be fixed?

Attachment 1: IMCsensingNoise.pdf
Attachment 2: IMCsensingNoise.pdf
  15514   Tue Aug 11 23:20:29 2020 gautamUpdateBHDSome first tests with air BHD setup

Some tests done today:

All of these tests were done with the PRMI locked with carrier resonant in the recycling cavity (i.e. sidebands rejected to REFL port). I then actuated the BS length DOF with a sine wave at 311.1 Hz, 40 cts amplitude (corresponding to ~8 pm of peak-to-peak displacement).

  1. Attempt to balance the DCPDs
    • I tried to tune the digital gains of the two DCPDs so as to minimize the appearance of this line in the SUM channel
    • but no matter how I tuned the gains, I couldn't make the line in the SUM channel disappear entirely - in fact, the best I could do was to make the line height in SUM and NULL channels (yes I recognize the poor channel name choice, I'll change "NULL" to "DIFF" at the next model recompile) the same. See Attachment #1.
    • The lobes around the main peak are indicative of some scattering?
    • Attachment #2 shows a wider frequency range. The homodyne phase isn't controlled, so the "NULL" channel is not necessarily measuring the correct quadrature to be sensing MICH motion.
    • I think I can back out something about the contrast defect from this fact, but I need to go back to some modeling.
  2. A simple test of the homodyne phase actuator
    • I wanted to check that this PI S320 piezo actually allows me to actuate the optical path length of the local oscillator.
    • I'm using the OMC HV driver to drive said PZT - so there are two DAC channels available, one to dither the optic and one to apply a control signal. I think mainly this is to avoid using up DAC range for the dither signal, the overall dynamic range is still limited by the HV supply.
    • I can't find the maximum voltage that can be applied on the datasheet - so conservatively, I limited the HV output to saturate at 100 V DC, as this is the maximum for the S330 piezos used for green steering, for which there is a manual.
    • The S320 manual does say the full stroke of each PZT element is 10 um - so the actuation coefficient is ~100 nm/V. I then drove this actuator with a sine wave of 500 cts amplitude, at 314.1 Hz (corresponding to 15 nm of motion). With only the LO beam incident on the PDs, I saw no signal in either DCPD - as expected, so this was good.
    • Then, with the PRMI locked, I repeated the test. If there is no DC light field (as expected for the PRMI in this configuration), I wouldn't expect this drive signal to show up in the DCPDs. But in fact, I do. Again, this supports the presence of some (for now unquantified) contrast defect.

While it would seem from these graphs that the RIN of the LO beam at these frequencies is rather high, it is because of the ADC noise. More whitening (to be installed in the coming days) will allow us to get a better estimate, should be ~1e-6 I think.

I was just playing today, still need to setup some more screens, DTT templates etc to do more tests in a convenient way.

Now, I can think about how to commission this setup interferometrically.

Attachment 1: PRMI_RFlock.pdf
Attachment 2: PRMI_RFlock_fullscale.pdf
  11998   Thu Feb 18 02:52:27 2016 ericqUpdateIOOSome housekeeping

I manually aligned the IMC. Spot positions are all < 1.5mm. PMC trans of ~0.74, MC2 Trans of ~15400, MC Refl ~0.4, which is better than its been for some time now.

Somehow the WFS DC offsets were off, which made it look like it was impossible to center the beam on WFS2. The script for setting these wasn't working so I fixed it, ran it. WFS and MC2 trans offsets were set, WFS are back on and have been holding MC REFL nice and low for ~3 hours.

Arms were dither aligned, wrote the offsets to SDF files. Oplevs need centering. No further daqd crashes.

  15308   Mon Apr 20 17:49:58 2020 gautamUpdateGeneralSome housekeeping
  • Empty N2 replaced. 
  • Logged back into zita and started the StripTool traces (even though we keep the TV off nowadays).
  • c1susaux acro-crate power cycled to re-enable PRM suspension control (all other vertex optics also now respond to slow bias voltage sliders being moved).
  • c1iscaux needed a hard reboot as it wasn’t seen on martian. I power cycled the crate for good measure.
  • Marconi turned back on with correct frequency/amplitude.
  • c0rga is now seen again on martian network. I re-enabled the RGA scanning so that it takes a scan every morning at 4am. 
  • The forepumps for TP2/TP3 are noisier than I remember. The former has ~10,000 hrs on the clock. How often does the tip seal replacement need to happen?
  • HV supplies for ASX/ASY PZTs re-energized.
  • IFO re-aligned for locking.
  • c1oaf and c1daf models restarted. c1oaf required the usual start/stop/start sequence to make the DAQ errors go away, and luckily the FE didn’t crash when the model was unloaded.
  • POX/POY/PRMI 1f carrier/green locking all was smooth.
  • For some reason, the PRC angular FF filters i trained no longer do anything good (but MCL is still good). collected 20mins of PRMI 1f locked data for investigations.
Update 21 Apr 2020 1200: Looking at Attachments #1 and #2, the spectra for motion sensed by the POP QPD does indeed look very different on Apr 6 vs Apr 20. Could be some interference from Oplev loop or maybe some EPICS values didn't get reset correctly, needs more investigation. It doesn't seem reasonable to me that the plant changes by so much (spectra were taken at similar times of the day, ~5pm).
Update 22 Apr 2020 1500: As suspected, the PRM oplev was disabled for whatever reason. Re-enabling it, I recovered the good performance from two weeks ago. ✅ 
Attachment 1: fDomainWF_Apr06.pdf
Attachment 2: fDomainWF_Apr20.pdf
ELOG V3.1.3-