ID |
Date |
Author |
Type |
Category |
Subject |
591
|
Sun Jun 29 11:31:52 2008 |
John | Summary | PSL | ISS |
I reduced the gain of the ISS (C1: PSL-ISS_VGAGAIN) from 5dB to 2dB. Any higher and it constantly saturates. |
595
|
Sun Jun 29 19:53:26 2008 |
John | Summary | PSL | ISS |
Quote: | I reduced the gain of the ISS (C1: PSL-ISS_VGAGAIN) from 5dB to 2dB. Any higher and it constantly saturates. |
Seemed to go back to normal after the frame builder came back. |
596
|
Sun Jun 29 20:09:40 2008 |
John | Summary | IOO | mcup and mcdown indicators |
I edited the mcup and mcdown scripts so that C1IFO_STATE shows when these scripts are running.
I also added indicators to the LockMC screen. |
Attachment 1: mcscreen.png
|
|
Attachment 2: ifostate.png
|
|
598
|
Mon Jun 30 01:49:06 2008 |
John | Update | IOO | MC work |
I'm in the process of aligning the mode cleaner/ input beam.
I turned off the WFS and cleared their histories, adjusted the input periscope and re-aligned the mode-cleaner accordingly.
I then unlocked the cavity and centred the beams on the WFS.
MC transmission is ~3.3 and the REFL beam looks a little better.
However, turning the WFS on now lowers the transmission. More thought tomorrow.
I'm leaving the MC locked with WFS off. |
601
|
Mon Jun 30 09:46:15 2008 |
John | Update | IOO | MC WFS |
MC WFS are on. They seem to do some good during the day. |
604
|
Mon Jun 30 15:08:52 2008 |
John | Summary | PSL | MZ alignment |
I adjusted the alignmnet of the Mach-Zehnder's two North mirrors (downstream of the EOMs).
MZ REFL is reduced from 0.54 to 0.43. The largest improvement was due to pitch on the PZT mirror. |
Attachment 1: mzalign.png
|
|
613
|
Tue Jul 1 12:51:34 2008 |
John | Summary | General | IFO alignment |
Rana, Rob, Yoichi, John
The recent computer problems and MZ work had disturbed the alignment of the interferometer.
We adjusted the MC alignment back to nominal positions using old OSEM values. We then walked
the input beam to match the MC. Coupling into the interferometer has increased noticeably.
The rest of the IFO was then aligned to the new input beam.
Proceeding to full IFO locking we were able to engage the AO path and hand off CARM to SPOBDC.
Arm powers got up to 4.
If the new alignment proves successful we will centre all QPDs etc so we can easily return to
this state. |
Attachment 1: align080701.png
|
|
618
|
Tue Jul 1 21:45:48 2008 |
John | Update | PSL | Mach Zehnder script and screen |
I've edited C1: PSL_MACH_ZEHNDER.adl and /cvs/cds/caltech/scripts/PSL/MZ/lockMZ
to reflect the changes described in entry #616. |
625
|
Wed Jul 2 17:19:03 2008 |
John | Summary | Computers | op440m - shutdown and restarted |
After 160days op440m was getting a little slow. |
626
|
Wed Jul 2 18:30:01 2008 |
John | Update | IOO | QPD alignment |
I aligned the beams on the following QPDs
IP POS
IP ANG
MC TRANS
IOO POS |
Attachment 1: IOO080702.png
|
|
Attachment 2: MC080702.png
|
|
633
|
Thu Jul 3 16:57:23 2008 |
John | Summary | General | FSS_RMTEMP |
The FSS room temp alarm has been beeping a lot recently. I altered the FSS_RMTEMP alarm levels using the
same method as Rana.
The alarm is still souding so, at least by my calculations, it must be colder than usual. |
Attachment 1: FSStime.png
|
|
Attachment 2: FSSalarm.png
|
|
644
|
Tue Jul 8 00:14:28 2008 |
John | Summary | Computers | Alarm handler |
Rob thought it would be nice to have some alarms on the cpu loads and FE syncs.
I added all these channels to the alarm handler config file and wrote a script
which would set their values (HIHI,HIGH etc).
Ezcawrite allowed me to set the alarm levels (and ezcaread would give the correct
value) but no matter what I set the value to the alarm wouldn't sound.
After experimenting with a few other channels it appears that the alarm handler will
not show alarms if the alarm levels are absent from the db file (even though ezca
gives a value).
I edited the following files so we can have alarms on the cpus.
In c1iscepics:
lsc40m.db
asc40m1.db
In c1losepics:
bs.db
etmx.db
etmy.db
itmx.db
itmy.db
mc1.db
mc2.db
mc3.db
prm.db
srm.db
I saved backups in the appropriate folders.
Next time we have a bootfest please also do c1iscepics and c1losepics so these changes
will be implemented. |
648
|
Tue Jul 8 12:25:54 2008 |
John | Summary | PSL | ISS gain set to 2dB |
|
651
|
Wed Jul 9 12:42:14 2008 |
John | Update | Locking | Hand off to RF CARM |
Rob, Yoichi, John
Last night we were able to reduce the CARM offset to around 80. This was achieved by increasing the DARM gain and
switching to AS_I when AS_Q went bad. This is probably a temporary solution, we will probably switch to DC readout
for DARM as we bring the arms on resonance.
Having reduced the arm offset enough to get us into the linear region of the RF_CARM signal (POX_I) we worked on
analogue conditioning of this signal to allow us to hand over. Lock was maintained for over 20 minutes as we did
this work.
We were able to partially switch over both the frequency and length paths to this new signal before losing lock. |
Attachment 1: LongLock080709.png
|
|
653
|
Wed Jul 9 17:58:19 2008 |
John | Summary | General | Illuminator alarms |
This morning some time was wasted on alignment due to the illuminators.
I added the illuminators to the alarm handler. They will give a RED alarm whenever
they are turned on. You can find the alarms in 40M->Misc->Illuminators.
To do this I edited the Illuminators.db file and restarted c1aux by telneting and typing Ctl-X.
I then added the groups and channels to 40M.alhConfig. |
657
|
Thu Jul 10 23:27:57 2008 |
John | Metaphysics | Cameras | Secret handshakes |
Rob and I have joined the ranks of the illuminati and exercised our power.
Quote: | Osamu showed me the secret way to change the video labels for the quads and
so we fixed them. He made me swear not to divulge this art.
- Rana Adhikari |
|
664
|
Sun Jul 13 22:39:16 2008 |
John | Summary | General | Edited medm screens |
I've edited the FSS and PMC screens so that red boxes are shown around the appropriate slider if a gain or offset is not within the limits defined in C1PSL_SETTINGS_SET.adl
With the current setting of 0 V the FSS input offset is red. According to the settings screen the nominal value is 0.3 +/- 0.050. Are there any objections to editing the nominal value?
I changed the LockMC screen so that red boxes are not shown when the up/down scripts are not running; when they are active you should see a green box. |
665
|
Mon Jul 14 00:36:19 2008 |
John | Summary | PSL | Slow sweep of laser temp - PMC PZT response |
John, Rana
Follow up to # 663
Top trace: C1: PSL-PMC_PZT
Middle: C1: PSL-FSS_SLOWDC
Bottom: C1: PSL-PMC_PMCTRANSPD
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
|
|
667
|
Mon Jul 14 12:43:07 2008 |
John | Summary | Computers | Restarted fb40m, tpman and c1ass |
|
675
|
Tue Jul 15 12:44:08 2008 |
John | Summary | Locking | DRFPMI with DC readout |
Rob, John
Last night, despite suspect alignment, we were again able to reduce the CARM offset to zero using
the RF signal.We were also able to transfer to dc readout taking calibrated spectra in both states.
DC readout shows a marked improvement over RF above ~1kHz but introduces some noise around 100Hz.
Broadband sensitivity appears to be more than ten times worse than previously. The calibration
being used remains to be confirmed.
Engaging the ETMY dewhitening caused lock to be lost. We'll check this today. The OMC alignment loops
may also need some attention.
We looked at REFL_166 as a candidate for CARM, at present POX still looks better.
The DARM filters were modified to reduce excess noise around 3Hz. Updating filter coefficients does
not cause loss of lock. |
684
|
Wed Jul 16 17:36:51 2008 |
John | DAQ | PSL | FSS input offset |
I changed the nominal FSS input offset to 0 from 0.3. Tolerance remains unchanged at +/-0.05. |
690
|
Thu Jul 17 13:08:37 2008 |
John | Summary | LSC | HOM resonances in the arms |
On Tuesday night we attempted to lock the full DRFPMI in the optical spring configuration with the +f2 sideband resonant in the SRC.
Despite having no problems locking on the +f2 in a DRM we couldn't lock the full IFO.
There was some discussion about whether a +f2 higher order mode resonance in the arms could cause this problem.
I calculated the positions of the first six higher order modes for the carrier and all sidebands (using Siegman p 762 (23) with a plus sign).
Plot attached. Colors indicate different frequency components, numbers are the mode index (m+n). Thick lines are fundamental modes of
the sidebands. Heights of HOM indicators have been scaled by 1/(m+n)^2.
It appears that the first order transverse mode of the +166 is indeed partially resonant. We might try to tweak the sideband frequencies a
little to see if this helps us. It would probably be prudent to measure the MC length first.
Numbers used:
L = 38.5750; %average of Alberto's recent measurements elog #556
Retm = 57.375;
f166 = 165.977195e6;
f33 = 33.195439e6; |
Attachment 1: HOMresonances.png
|
|
830
|
Tue Aug 12 21:38:19 2008 |
John | Update | LSC | Accidental higher order mode resonances in the arms |
Recently we had been having some trouble locking the full IFO in the spring configuration (SRC on +166).
It was thought that an accidental higher order mode resonance in the arms may have been causing problems.
I previously calculated the locations of the resonances using rough arm cavity parameters(Elog #690). Thanks to Koji
and Alberto I have been able to update this work with measured arm length and g factors for the y arm (Elog #801,#802).
I have also included the splitting of the modes caused by the astigmatic ETM. Code is attached.
I don't see any evidence of +166MHz resonances in the y arm.
In the attached plot different colours denote different frequencies +33, -33, +166, -166 & CR.
The numbers above each line are the mn of TEMmn.
Solid black line is the carrier resonance. |
Attachment 1: HOMresonances.png
|
|
Attachment 2: HOMarms2.m
|
%Check for accidental resonances of HOM in the arms (maybe due to
%sidebands). At the moment there is only data for the y arm.
clear all
close all
clc
%Stuff one might change often
modeorder = 0:5; % Look for TEMmn modes where m,n run over modeorder
... 157 more lines ...
|
858
|
Wed Aug 20 11:42:49 2008 |
John | Summary | Computers | pdftk |
I've installed pdftk on all the control room machines.
http://www.pdfhacks.com/pdftk/ |
859
|
Wed Aug 20 11:50:10 2008 |
John | Summary | Computers | StripTools on op540m |
To restart the striptools on op540m:
cd /cvs/cds/caltech/scripts/general/
./startstrip.csh |
14111
|
Sat Jul 28 22:16:49 2018 |
John Martyn | Update | | Characterization of Transimpedance Amplifier |
Kevin and I meaured the transfer function of the photodiode circuit using the Jenne laser and agilent in the 40m lab. The attached figures depict our measured transfer function over the modulation frequency ranges of 30kHz-30MHz and 1kHz-30MHz when the power of the laser was set to 69 and 95 μW. These plots indicate a clear roll off frequency around 300 kHz. In addition, the plots beginning at 1kHz display unstable behavior at frequencies below 30kHz. I am not sure why there is such a sharp change in the transfer function around 30kHz, but I suspect this to be due to an issue with the agilent or photodiode. |
Attachment 1: PD_TF1.pdf
|
|
Attachment 2: PD_TF2.pdf
|
|
Attachment 3: PD_and_TIA_Transfer_Function_Measurements.zip
|
8757
|
Wed Jun 26 15:11:08 2013 |
John Zweizig | Update | SUS | NDS2 Status |
Quote: |
I've restarted the NDS2 process on Megatron so that we can use it for getting past data and eventually from outside the 40m.
1) from /home/controls/nds2 (which is not a good place for programs to run) I ran nds2-megatron/start-nds2
2) this is just a script that runs the binary from /usr/bin/ and then leaves a log file in ~/nds2/log/
3) I tested with DTT that I could access megatron:31200 and get data that way.
There is a script in usr/bin called nds2_nightly which seems to be the thing we should run by cron to get the channel list to get updated, but I' m not sure. Let's see if we can get an ELOG entry about how this works.
Then we want Jamie to allow some kind of tunneling so that the 40m data can be accessed from outside, etc.
|
I have done the following:
* installed the nds2-client in /ligo/apps/nds2-client
* moved the nds2 configuration directories to /ligo/apps/nds2/nds2-megatron
* set up a cron job to update the channel list every morning at 5 am. The cron line is:
15 5 * * * /usr/bin/nds2_nightly /ligo/apps/nds2/channel-tracker /ligo/apps/nds2/nds2-megatron
cron will send an email each time the channel list changes, at which point you will have to restart the server with:
cd /ligo/apps/nds2/nds2-megatron
pkill nds2
./start-nds2
* restarted nds2 with updated channel lists. |
8787
|
Fri Jun 28 17:33:33 2013 |
John Zweizig | Update | SUS | NDS2 Status |
Quote: |
Quote: |
I've restarted the NDS2 process on Megatron so that we can use it for getting past data and eventually from outside the 40m.
1) from /home/controls/nds2 (which is not a good place for programs to run) I ran nds2-megatron/start-nds2
2) this is just a script that runs the binary from /usr/bin/ and then leaves a log file in ~/nds2/log/
3) I tested with DTT that I could access megatron:31200 and get data that way.
There is a script in usr/bin called nds2_nightly which seems to be the thing we should run by cron to get the channel list to get updated, but I' m not sure. Let's see if we can get an ELOG entry about how this works.
Then we want Jamie to allow some kind of tunneling so that the 40m data can be accessed from outside, etc.
|
I have done the following:
* installed the nds2-client in /ligo/apps/nds2-client
* moved the nds2 configuration directories to /ligo/apps/nds2/nds2-megatron
* set up a cron job to update the channel list every morning at 5 am. The cron line is:
15 5 * * * /usr/bin/nds2_nightly /ligo/apps/nds2/channel-tracker /ligo/apps/nds2/nds2-megatron
cron will send an email each time the channel list changes, at which point you will have to restart the server with:
cd /ligo/apps/nds2/nds2-megatron
pkill nds2
./start-nds2
* restarted nds2 with updated channel lists.
|
I have set the cron job up to restart the nds2 server automatically if the channel list changes. The only change is that the cron command was changes to /ligo/apps/nds2/nds2-megatron/test-restart.
|
9216
|
Mon Oct 7 18:32:01 2013 |
John Zweizig | Summary | Computer Scripts / Programs | nds2 installed, restarted |
The upgrade of megatron broke the nds2 service. I have fixed things by
1) installing the latest version of framecpp (1.19.32) from the lsc debian repository (this was necessary because I couldn't link to the existing version)
2) built nds2-server-0.5.11 and installed it in the system directories (/usr/bin)
3) there were a few scripts/links/etc that didn't seem to be set up correctly and I fixed them to correspond with my preious message.
nds2 is now running and the channel list should be updated regularly and the service restarted as appropriate.
|
612
|
Tue Jul 1 12:08:38 2008 |
John, Joe | Configuration | PSL | PMC input PD |
Joe and I switched cables so that the PMCR screen actually shows reflection not transmission.
The trans camera had a BNC connected to "video out" labelled PMC input PD. The video signal
going to the monitors does not come from "video out", it comes out the "DC in/sync" cable.
As far as we can see this diode doesn't exist. Where should the PMC input PD BNC cable be
connected? |
602
|
Mon Jun 30 13:48:47 2008 |
John, Rob | Configuration | PSL | Don't put the bin in front of the air conditioning unit |
We spotted that the laser power was dropping.
The air conditioning unit was blocked by the blue bin/trash can/cestino causing the laser head temp to increase by 2 degrees.
Let's be careful about this in the future. |
Attachment 1: binremoval.png
|
|
711
|
Tue Jul 22 03:03:22 2008 |
John, Rob | Update | PSL | FSS open loop transfer function |
With the common gain slider maxed out the unity gain frequency is 58kHz.
The reference cavity refl diode appears to be okay. RF OUT/ TEST IN transfer function was normal.
There is a ~220mV offset in the RF out. We removed this using a coupler - no change. We also checked the
diode->FSS cable.
Tomorrow I'll take a closer look at the board. |
715
|
Tue Jul 22 13:16:09 2008 |
John, Rob | Update | PSL | FSS open loop transfer function |
Quote: | With the common gain slider maxed out the unity gain frequency is 58kHz.
The reference cavity refl diode appears to be okay. RF OUT/ TEST IN transfer function was normal.
There is a ~220mV offset in the RF out. We removed this using a coupler - no change. We also checked the
diode->FSS cable.
Tomorrow I'll take a closer look at the board. |
Should note that the UGF of 58kHz was measured with the test cable (from RFPD to board), so the demod phase was presumably sub-optimal. |
13976
|
Sat Jun 16 20:57:59 2018 |
Jon | Update | General | PRC modescan attempt |
Here's a Finesse modeling of what we're expecting to observe with this test. It uses Gautam's base model of the 40m IFO with appropriate modifications for the needed configuration.
The idea is to lock the IFO in the SRMI configuration, with the phase-locked AUX beam injected from the AS port. The AUX beam is imprinted with AM sidebands and slightly misaligned relative to the SRC so as to transfer power into HOM1. The RF network analyzer provides the drive signal for the AOM, and its frequency is swept to coherently measure the transfer function [reflected AUX beam / drive]. The reflected AUX beam is sensed by the AS110 PDA10CF.
It is also possible to drive PM sidebands as Koji suggests, but the squeezer group has encouraged using AM for practical advantages. The SNR with AM is a bit higher (less power lost into harmonics at large modulation index), there is a broadband AOM already available aligned to the SQZ beam at LLO, and there is also concern that driving strong PM could interfere with the SQZ control loops.
Expected SRMI Response
Attachment #1 shows the expected response to swept-AM in SRMI. Resolving just the FSR and the first-order mode splitting is sufficient to extract the SRC Gouy phase.
Expected response in the SRMI configuration.
Expected DRMI Response
Since the 40m has not been opearted in SRMI since ~2016 (last done by Eric Q.), Gautam believes it may take some time to relock this configuration. However, the modeling indicates that we can likely obtain sufficient sensitivity in DRMI, which would allow us to proceed faster. Attachment #2 shows the expected response to swept-AM in DRMI. The PRC leakage signal turns out to be significantly smaller than the SRC reflection (a factor of ~30 in amplitude), so that the signal still retains its characteristic shape to a very good approximation. The tradeoff is a 10x reduction in SNR due to increased PSL shot noise reaching AS110.
Expected DRMI response. The main difference is a 10x increase in shot noise on AS110.
Based on this, we should proceed with DRMI scans instead of PRMI next week.
Quote: |
The PRC FSR is, of course, very close to twice of our f1 moudlation frequency (11MHz x 2 = 22MHz) .
I still don't understand what response the measurement is looking for. I understood the idea of using the subcarrier as a stablized carrier to the PRC with a certain freq offset from the main carrier. I suppose what was swept was the AOM modulation frequency (i.e. modulation frequency of the AM applied to the subcarrier). If that is the case, the subcarrier seemed fixed at an arbitorary frequency (i.e. 50MHz) away from the carrier. If one of the AM sidebands hits the PRC resonance (i.e. 22, 44, 66MHz away from the main carrier), you still have the other sideband reflected back to the AS. Then the RF signal at the AS is still dominated by this reflected sideband. I feel that the phase modulation is rather suitable for this purpose.
If you are talking about ~MHz AM modulation by the AOM and scanning the PLL frequency from 1MHz to 60MHz, the story is different. And this should involve demodulation of the AS signal at the AM modulation frequency. But I still don't understand why we don't use phase modulation, which gives us the PDH type signal at the reflection (i.e. AS) port...
|
|
Attachment 1: 40M_SRMI_AM_annotated.pdf
|
|
Attachment 2: 40M_DRMI_AM.pdf
|
|
13987
|
Tue Jun 19 18:56:55 2018 |
Jon | Update | General | AUX beam alignment issues |
Not much progress today with the AUX cavity scans. I've determined there still are some alignment issues.
At the start of today a large AUX/PSL beat note was visible on the AS110 sensor, at a similar power as where we left off last night (-60 dBm). Proceeding from there, I attempted to reproduce Johannes' measurement of the cavity transmission resonances. I misaligned the X-arm, locked the Y-arm cavity, and scanned the AUX RF offset approximately 8 MHz in 2 kHz steps. This should have swept through two FSRs, but nothing was visible.
Further inspection revealed that none of the PSL light was making it back to through the AUX fiber to the PSL table. I take this to mean that the beam seen earlier on AS110 was the ITMY reflection, and that the AUX injection axis was no longer reaching ETMY. I also found that the AUX beam size just after the 90/10 beasmsplitter looks anomolously large. Maybe a lens was recently changed? In any case, the mode-matching looks like it is going to need to be readjusted. |
13994
|
Thu Jun 21 09:33:02 2018 |
Jon | Update | | AUX Mode Scans of YARM, PRC cavities |
[Jon, Keerthana, Sandrina]
Yesterday we carried out preliminary proof-of-concept measurements using the new AS-port-injected AUX laser to resolve cavity mode resonances.
At the time we started, I found the beat note levels consistent with what Johannes had reported the night before post-realignment. Hence we did not change the AUX alignment.
Test 1: YARM Mode Scan
- IFO locked in YARM configuration on carrier.
- Confirmed the presence of a -80 dBm beat note on the temporary YEND broadband PD (i.e., at the cavity transmission).
- Slowly canned the RF offset of the AUX laser from 50 MHz (nominal) to 60 MHz in 10 kHz steps.
- Attachment 1 shows the measured scan in "max hold" mode. The bottom panel is the transmission spectrum and the top panel is the reflection, with the AUX/PSL carrier-carrier beat note visible to the far left. In addition to the FSR, it looks to me like the scan resolves at least two HOMs.
Test 2: PRC Mode Scan
- IFO locked in PRMI configuration on carrier.
- Moved the temporary 150 MHz PDA10CF from the YEND to an unused pickoff of the REFL33 beam (i.e., the PRC transmission of the AUX beam). There was an existing 50-50 beamsplitter just before REFL33 whose reflected beam was directed onto a beam dump. The PD is now placed in that location. The modification to the AS table is shown in Attachment 2.
- We made a similar slow scan of the AUX RF offset over ~35 MHz in 10 kHz steps.
- We resolve the 22 MHz FSR, but it is apparent that an incoherent "max-hold" analyzer measurement is inadequate. The problem is that in max-hold mode, because the 11 MHz-spaced PSL sidebands also beat with the AUX subcarrier, we measure a messy superposition of the PSLcarrier-AUXcarrier beat AND all of the PSLsideband-AUXcarrier beats. The next step is to use the AOM to make a coherent measurement at only the frequency of PSL/AUX carrier-carrier beat.
The SURFs have the data from last night's scans and will be separately posting plots of these measurements. We'll continue today with mode scans using AM sidebands rather than the AUX RF offset. |
Attachment 1: YARM_AUX_RF-offset_scan.pdf
|
|
Attachment 2: temp_broadband_refl33.pdf
|
|
14010
|
Sat Jun 23 13:08:41 2018 |
Jon | Update | AUX | First Coherent AUX Scan of PRC Using AM Sidebands |
[Jon, Keerthana, Sandrine]
Thu.-Fri. we continued with PRC scans using the AUX laser, but now the "scanned" parameter is the frequency of AM sidebands, rather than the frequency of the AUX carrier itself. The switch to AM (or PM) allows us to coherently measure the cavity transfer as a function of modulation frequency.
In order to make a sentinel measurement, I installed a broadband PDA255 at an unused pickoff behind the first AUX steering mirror on the AS table. The sentinel PD measures the AM actually imprinted on the light going into the IFO, making our measurement independent of the AOM response. This technique removes not only the (non-flat) AOM transfer function, but also any non-linearities from, e.g., overdriving the AOM. The below photo shows the new PD (center) on the AS table.

With the sentinel PD installed, we proceeded as follows.
- Locked IFO in PRMI on carrier.
- Locked AUX PLL to PSL.
- Tuned the frequency of the AUX laser (via the RF offset) to bring the carrier onto resonance with the PRC.
- Swept the AOM modulation frequency 0-60 MHz while measuring the AUX reflection and injection signals.
The below photo shows the measured transfer function [AUX Reflection / AUX Injection]. The measurement coherence is high to ~55 MHz (the AOM bandwidth is 60 MHz). We clearly resolve two FSRs, visible as Lorentzian dips at which more AUX power couples into the cavity. The SURFs have these data and will be separately posting figures for the measurements.

With the basic system working, we attempted to produce HOMs, first by partially occluding the injected AUX beam with a razor blade, then by placing a thin two-prong fork in the beam path. We also experimented with using a razor blade on the output to partially occlude the reflection beam just before the sensor. We were able to observe an apparent secondary dip indicative of an HOM a few times, as shown below, but could not repeat this deterministically. Besides not having fine control over the occlusion of the beams, there is also large few-Hz angular noise shaking the AS beam position. I suspect from moment to moment the HOM content is varying considerably due to the movement of the AS beam relative to the occluding object. I'm now thinking about more systematic ways to approach this.

|
14020
|
Tue Jun 26 17:20:33 2018 |
Jon | Configuration | Cameras | LLO Python Camera Software is Working |
Thanks to a discussion yesterday with Joe Betzweiser, I was able to identify and fix the remaining problem with the LLO GigE camera software. It is working now, currently only on rossa, but can be set up on all the machines. I've started a wiki page with documentation and usage instructions here:
https://wiki-40m.ligo.caltech.edu/Electronics/GigE_Cameras
This page is also linked from the main 40m wiki page under "Electronics."
This software has the ability to both stream live camera feeds and to record feeds as .avi files. It is described more on the wiki page. |
14033
|
Fri Jun 29 18:16:32 2018 |
Jon | Configuration | PSL | Changes to AUX Optical Layout on PSL Table |
In order to use the 0th-order deflection beam from the AOM for cavity mode scans, I've coaligned this beam to the existing mode-matching/launch optics set up for the 1st-order beam.
Instead of being dumped, the 0th-order beam is now steered by two 45-degree mirrors into the existing beam path. The second mirror is on a flip mount so that we can quickly switch between 0th-order/1st-order injections. None of the existing optics were touched, so the 1st-order beam alignment should still be undisturbed.
Currently the 0th-order beam is being injected into the IFO. After attenuating so as to not exceed 100 mW incident on the fiber, approximately 50 mW of power reaches the AS table. That coupling efficiency is similar to what we have with the 1st-order beam. With the Y-arm cavity locked and the AUX PLL locked at RF offset = 47.60 MHz (an Y-arm FSR), I observed a -50 dBm beat note at Y-end transmission. |
Attachment 1: PSL_AUX_SETUP_CHANGE.pdf
|
|
14035
|
Tue Jul 3 11:59:10 2018 |
Jon | Update | AUX | AUX Carrier Scan of Y-Arm Cavity |
I made the first successful AUX laser scan of a 40m cavity last night.
Attachment #1 shows the measured Y-end transmission signal w.r.t. the Agilent drive signal, which was used to sweep the AUX carrier frequency. This is a distinct approach from before, where the carrier was locked at a fixed offset from the PSL carrier and the frequency of AM sidebands was swept instead. This AUX carrier-only technique appears to be advantageous.
This 6-15 MHz scan resolves three FSR peaks (TEM00 resonances) and at least six other higher-order modes. The raw data are also enclosed (attachment #2). I'll leave it as an excercise for the SURFs to compute the Y-arm cavity Gouy phase. |
Attachment 1: yarm_carrier_trans.pdf
|
|
Attachment 2: AG4395A_02-07-2018_185504.txt
|
# AG4395A Measurement - Timestamp: Jul 02 2018 - 18:55:04
#---------- Measurement Parameters ------------
# Start Frequency (Hz): 6000000.0, 6000000.0
# Stop Frequency (Hz): 15000000.0, 15000000.0
# Frequency Points: 801, 801
# Measurement Format: LOGM, PHAS
# Measuremed Input: AR, AR
#---------- Analyzer Settings ----------
# Number of Averages: 16
# Auto Bandwidth: Off, Off
... 807 more lines ...
|
14036
|
Wed Jul 4 19:11:49 2018 |
Jon | Update | AUX | More Testing of AUX-Laser Mode Scanning |
More progress on the AUX-laser cavity scans.
Changes to the Setup
- For scans, the Agilent is now being used as a standalone source of the LO signal provided to the AUX PLL (instead of the Marconi), which sets the RF offset. We discovered that when the sweep is "held" in network analyzer mode, it does not turn off the RF drive signal, but rather continues outputting a constant signal at the hold frequency. This eliminates the need to use the more complicated double-deomdulation previously in use. The procedure is to start and immediately hold the sweep, then lock the PLL, then restart the sweep. The PLL is able to reliably remain locked for frequency steps of up to ~30 kHz. The SURFs are preparing schematics of both the double- and single-demodulation techniques.
- Both the Marconi and Agilent are now phase-locked to the 10 MHz time reference provided by the rabidium clock. This did noticeably shift the measured resonance frequencies.
- I raised the PI controller gain setting to 4.5, which seems to better suppress the extra noise being injected.
- I've procured a set of surgical needles for occluding the beam to produce HOMs. However, I have not needed to use them so far, as the TEM00 purity of the AUX beam appears to already be low. The below scans show only the intrinisic mode content.
New Results
- YARM scan at 70 uW injection power (Attachment #1). The previously reported YARM scan was measured with 9 mW of injected AUX power, 100x larger than the power available from the SQZ laser at the sites. This scan repeats the measurement with the AUX power attenuated to uW. It still resolves the FSR and at least three HOMs.
- PRC scan (Attachment #2) at 9 mW injection power. It appears to resolve the FSR and at least three HOMs. Angular injection noise was found to cause large fluctuations in the measured signal power. This dominates the error bars shown below, but affects only the overall signal amplitude (not the peak frequency locations). The SQZ angular alignment loops should mitigate this issue at the sites.
Both data sets are attached. |
Attachment 1: yarm_trans_70uW.pdf
|
|
Attachment 2: prc_trans_9mW.pdf
|
|
Attachment 3: yarm_carrier_trans_70uW.tar.gz
|
Attachment 4: prc_carrier_trans_9mW.tar.gz
|
14044
|
Sun Jul 8 12:20:12 2018 |
Jon | Summary | AUX | Gouy Phase Measurements from AUX-Laser Scans |
This note reports analysis of cavity scans made by directly sweeping the AUX laser carrier frequency (no sidebands). The measurement is made by sweeping the RF offset of the AUX-PSL phase-locked loop and demodulating the cavity reflection/transmission signal at the offset frequency.
Y-Arm Scan
Due to the simplicity of its expected response, the Y-arm cavity was scanned first as a test of the AUX hardware and the sensitivity of the technique. Attachment 1 shows the measured cavity transmission with respect to RF drive signal.

The AUX laser launch setup is capable of injecting up to 9.3 mW into the AS port. This high-power measurement is shown by the black trace. The same measurement is repeated for a realistic SQZ injection power, 70 uW, indicated by the red curve. At low power, the technique still clearly resolves the FSR and six HOM resonances. From the identified mode resonance frequencies the following cavity parameters are directly extracted.
YARM |
Gautam's Finesse Model |
Actual |
FSR |
3.966 MHz |
3.967 MHz |
Gouy phase |
54.2 deg |
52.0 deg |
PRC Scan
An analogous scan was performed for the PRC, with the IFO locked on PSL carrier in PRMI. Attachment 2 shows the measurement of PRC transmission with respect to drive signal.

The scan resolves HOM resonances to at least ~13th order, whose frequencies yield the following cavity parameters.
PRC |
Gautam's Finesse Model |
Actual |
FSR |
22.30 MHz |
22.20 MHz |
Gouy phase |
13.4 deg |
15.4 deg |
SRC Scan
Ideally (and at the sites) the SRC mode resonances will be measured in SRMI configuration. Because every other cavity is misaligned, this configuration provides an easily-interpretable spectrum whose resonances can all be attributed to the SRC.
Due to time constraints at the 40m, the IFO could not be restored to lockability in SRMI. It has been more than two years since this configuration was last run. For this reason the scan was made instead with the IFO locked in DRMI, as shown in Attachment 3. The quantity measured is the AUX reflection with respect to drive signal.
This result requires far more interpretation because resonances of both the SRC and PRC are superposed. However, the resonances of the PRC are known a priori from the independent PRMI scan. The SRC mode resonances identified below do not conincide with any of the first five PRC mode resonances.

Based on the identified mode resonance frequencies, the SRC parameters are measured as follows.
SRC |
Gautam's Finesse Model |
Actual |
FSR |
27.65 MHz |
27.97 MHz |
Gouy phase |
10.9 deg |
8.8 deg |
Lessons Learned
From experience with the 40m, the main challenges to repeating this measurement at the sites will be the following.
- Pointing jitter of the input AUX beam. This causes the PSL-AUX beam overlap to vary at transmission (or reflection), causing variation in the amplitude of the AUX-PSL beat note. As far as we can tell, the frequency of the resonances (the only object of this measurement) is not changing in time, only the relative amplitudes of the diferent mode peaks. I believe the SQZ alignment loops will mitigate this problem at the sites.
- Stabilization of the network analyzer time base. We found the intrinsic frequency stability of the network analyzer (Agilent 4395A) to be unacceptably large. We solved this problem by phase-locking the Agilent to an external reference, a 10-MHz signal provided by an atomic clock.
|
Attachment 1: yarm_aux_carrier_trans.pdf
|
|
Attachment 2: prmi_aux_carrier_trans.pdf
|
|
Attachment 3: drmi_aux_carrier_trans.pdf
|
|
14091
|
Fri Jul 20 18:30:47 2018 |
Jon | Configuration | AUX | Recommend to install AUX PZT driver |
I recently realized that the PLL is only using about 20% of the available actuation range of the AUX PZT. The +/-10 V control signal from the LB1005 is being directly inputted into the fast AUX PZT channel, which has an input range of +/-50 V.
I recommend to install a PZT driver (amplifier) between the controller and laser to use the full available actuator range. For cavity scans, this will increase the available sweep range from +/-50 MHz to +/-250MHz. This has a unique advantage even if slow temperature feedback is also implemented. To sample faster than the timescale of most of the angular noise, scans generally need to be made with a total sweep time <1 sec. This is faster than the PLL offset can be offloaded via the slow temperature control, so the only way to scan more than 100 MHz in one measurement is with a larger dynamic range. |
14171
|
Mon Aug 20 15:16:39 2018 |
Jon | Update | CDS | Rebooted c1lsc, slow machines |
When I came in this morning no light was reaching the MC. One fast machine was dead, c1lsc, and a number of the slow machines: c1susaux, c1iool0, c1auxex, c1auxey, c1iscaux. Gautam walked me through reseting the slow machines manually and the fast machines via the reboot script. The computers are all back online and the MC is again able to lock. |
14179
|
Thu Aug 23 15:26:54 2018 |
Jon | Update | IMC | MC/PMC trouble |
I tried unsuccessfully to relock the MC this afternoon.
I came in to find it in a trouble state with a huge amount of noise on C1:PSL-FSS_PCDRIVE visible on the projector monitor. Light was reaching the MC but it was unable to lock.
- I checked the status of the fast machines on the CDS>FE STATUS page. All up.
- Then I checked the slow machine status. c1iscaux and c1psl were both down. I manually reset both machines. The large noise visible on C1:PSL-FSS_PCDRIVE disappeared.
- After the reset, light was no longer reaching the MC, which I take to mean the PMC was not locked. On the PSL>PMC page, I blanked the control signal, reenabled it, and attempted to relock by adjusting the servo gain as Gautam had showed me before. The PMC locks were unstable, with each one lasting only a second or so.
- Next I tried restoring the burt states for c1iscaux and c1psl from a snapshot taken earlier today, before the machine reboots. That did not solve the problem either.
|
14187
|
Tue Aug 28 18:39:41 2018 |
Jon | Update | CDS | C1LSC, C1AUX reboots |
I found c1lsc unresponsive again today. Following the procedure in elog #13935, I ran the rebootC1LSC.sh script to perform a soft reboot of c1lsc and restart the epics processes on c1lsc, c1sus, and c1ioo. It worked. I also manually restarted one unresponsive slow machine, c1aux.
After the restarts, the CDS overview page shows the first three models on c1lsc are online (image attached). The above elog references c1oaf having to be restarted manually, so I attempted to do that. I connect via ssh to c1lsc and ran the script startc1oaf. This failed as well, however.
In this state I was able to lock the MICH configuration, which is sufficient for my purposes for now, but I was not able to lock either of the arm cavities. Are some of the still-dead models necessary to lock in resonant configurations? |
Attachment 1: CDS_FE_STATUS.png
|
|
14190
|
Wed Aug 29 11:46:27 2018 |
Jon | Update | SUS | local 4.4M earth quake |
I freed ITMX and coarsely realigned the IFO using the OPLEVs. All the alignments were a bit off from overnight.
The IFO is still only able to lock in MICH mode currently, which was the situation before the earthquake. This morning I additionally tried restoring the burt state of the four machines that had been rebooted in the last week (c1iscaux, c1aux, c1psl, c1lsc) but that did not solve it.
Quote: |
All suspension tripped. Their damping restored. The MC is locked.
ITMX-UL & side magnets are stuck.
|
|
14196
|
Mon Sep 10 12:44:48 2018 |
Jon | Update | CDS | ADC replacement in c1lsc expansion chassis |
Gautam and I restarted the models on c1lsc, c1ioo, and c1sus. The LSC system is functioning again. We found that only restarting c1lsc as Rolf had recommended did actually kill the models running on the other two machines. We simply reverted the rebootC1LSC.sh script to its previous form, since that does work. I'll keep using that as required until the ongoing investigations find the source of the problem.
Quote: |
Looks like the ADC was not to blame, same symptoms persist.
Quote: |
The PCIe fiber replacement is a more involved project (Steve is acquiring some protective tubing to route it from the FE in 1X6 to the expansion chassis in 1Y3), but hopefully the problem was the ADC card with red indicator light, and replacing it has solved the issue.
|
|
|
14278
|
Tue Nov 6 19:41:46 2018 |
Jon | Omnistructure | | c1vac1/2 replacement |
This afternoon I started setting up the Supermicro 5017A-EP that will replace c1vac1/2. Following Johannes's procedure in 13681 I installed Debian 8.11 (jessie). There is a more recent stable release, 9.5, now available since the first acromag machine was assembled, but I stuck to version 8 for consistency. We already know that version to work. The setup is sitting on the left side of the electronics bench for now. |
14282
|
Wed Nov 7 19:17:18 2018 |
Jon | Omnistructure | | modbusIOC is running on c1vac replacement |
Today I finished setting up the server that will replace the c1vac1/2 machines. I put it on the martian network at the unassigned IP 192.168.113.72. I assigned it the hostname c1vac and added it to the DNS lookup tables on chiara.
I created a new targets directory on the network drive for the new machine: /cvs/cds/caltech/target/c1vac. After setting EPICS environment environment variables according to 13681 and copying over (and modifiying) the files from /cvs/cds/caltech/target/c1auxex as templates, I was able to start a modbusIOC server on the new machine. I was able to read and write (soft) channel values to the EPICS IOC from other machines on the martian network.
I scripted it as a systemd-managed process which automatically starts on boot and restarts after failure, just as it is set up on c1auxex. |