40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 104 of 341  Not logged in ELOG logo
ID Date Author Typeup Category Subject
  2548   Tue Jan 26 19:51:44 2010 Sanjit, ranaUpdateAdaptive FilteringOAF details

We turned on the OAF again to make sure it works. We got it to work well with the Ranger as well as the Guralp channels. The previous problem with the ACC is that Sanjit and Matt were using the "X" channels which are aligned the "Y" arm. Another casualty of our ridiculous and nonsensical coordinate system. Long live the Right Hand Rule!!

The changes that were made are:

  • use of RANGER channel (with ACC_MC1_X and/or ACC_MC2_X)
  • mu = 0.01, tau = 1.0e-6, ntaps = 2000, nDown = 16
  • nDelay = 5 and nDelay = 7 both work (may not be so sensitive on delay at low frequencies)
  • Main changes: filter bank on the PEM channels - ASS_TOP_PEM_## filters: 0.1:0, 1:, Notch24, AA32, gain 1
  • Added the AI800 filter for upsampling in MC1 (should not matter)

Other parameters which were kept at usual setting:

  • CORR: AI32, gain = 1
  • EMPH: 0.001:0, AA32, gain = 1
  • ERR_MCL: no filters, gain = 1
  • SUS_MC1: no filter, gain = 1
  • PEM Matrix: All zero except: (24,1), (15,2), (18,3)
  • ADAPT path filter: union of CORR and EMPH filters, gain 1
  • XYCOM switches # 16-19 (last four on the right) OFF 

Screenshots are attached.

Burt snapshot is kept as: /cvs/cds/caltech/scripts/OAF/snaps/ass_burt_100126_211330.snap

taken using the script: /cvs/cds/caltech/scripts/OAF/saveOAF

we should put this in ASS screen.


ERROR Detected in filter ASS_TOP_PEM_24 (RANGER): 1: was actually typed as a 1Hz high pass filter!

(Correcting this one seems to spoil the adaptation)

Possibly this makes sense, we may not want to block witness signals in the 0.1-20 Hz range.


  11:40 PM: Leaving the lab with the OAF running on 5 PEM channels (Ranger + Guralp 1&2  Y & Z). There's a terminal open on op440m which will disable the OAF in ~2.8 hours. Feel free to disable sooner if you need the MC/IFO.

Attachment 1: C1ASS_TOP.png
C1ASS_TOP.png
Attachment 2: C1SUS_SRM_XYCOM1.png
C1SUS_SRM_XYCOM1.png
Attachment 3: Untitled.png
Untitled.png
  2550   Wed Jan 27 11:02:30 2010 AlbertoUpdateABSLPRC Cavity Length
 I fitted the data from scanning the PRC by changing the beat frequency of the auxiliary laser beam with the PSL beam.
The data points that I've taken so far over the entire frequency range (0-300 MHz) are not continuous. For several reasons the PLL was unable to maintain lock for such a large range and I had to break it into smaller segments. The measurements to acquire them stretched over a too long period of time during which the status of the PRC changed.
 
Because of that, before I get a continuous set of data points (perhaps normalized by the circulating power inside of the cavity), I restricted the fit to a 55MHz range around 100MHz. I obtained the following numbers for the fit parameters:
Length PRC = 2.169 +/- 0.007 m
Schnupp Asymmetry: 0.471+/- 0.006 m
 
The fit is shown in the attached plot:
2010-01-21_PRCtransmissivityVsFit.png
When I fit over the entire set of data I get this:
 
2010-01-21_PRCtransmissivity_EntireFreqRange_VsFit.png
 
Length PRC = 2.224 +/- 0.005 m
Schnupp Asymmetry: 0.457+/- 0.005 m
 
The results are different. Evidently I have to improve the measurement. I'm working on it.
 
For posterity:
The function I used to fit the transmitted beat power vs. frequency is the following:
 
E_trans = - t_prm * r_itm * exp(1i*2*wb*l_prc/c) .* sin(wb*l_/c) ./ ( 1 + r_prm * r_itm * exp(1i*2*wb*l_prc/c) .* cos(wb*l_/c)
 
Where wb is the angular frequency of the beat, l_prc and l_ are the length of the PRC and the Schnupp asymmetry, respectively; r_itm, t_itm, r_prm, t_prm are reflectances and transmittances of PRM and ITM; c is the speed of light.
 
  2552   Thu Jan 28 09:17:32 2010 AlbertoUpdateLSC166 Modulation turned off

I temporarily turned off the 166 modulation.

  2553   Fri Jan 29 12:06:58 2010 AlbertoUpdateABSLMeasurement running today at lunch time

I just started a measuremtn that will be running for the next hour or so. Please be careful with the interferometer.

  2554   Fri Jan 29 13:14:49 2010 AlbertoUpdateABSLMeasurement running today at lunch time

Quote:

I just started a measuremtn that will be running for the next hour or so. Please be careful with the interferometer.

Done. IFO available

  2555   Mon Feb 1 18:31:00 2010 SanjitUpdateAdaptive FilteringOAF details

  I tried downsampling value 32 (instead of 16), to see if it has any effect on OAF. Last week I encountered some stability issue - adaptation started to work, but the mode cleaner was suddenly unlocked, it could be due to some other effect too.

One point to note is that different downsampling did not have any effect on the CPU meter (I tried clicking the "RESET" button few times, but no change).

  2556   Mon Feb 1 18:33:10 2010 steveUpdateMOPAVe half the lazer!

The 2W NPRO from Valera arrived today and I haf hidden it somewere in the 40m lab!

 

Rana was so kind to make this entry for me

Attachment 1: inno2w.JPG
inno2w.JPG
Attachment 2: inno2Wb.JPG
inno2Wb.JPG
  2557   Mon Feb 1 21:51:12 2010 SanjitUpdateAdaptive FilteringOAF details

 I tried some combination of PEM channels and filters to improve OAF performance at other frequencies, where we do not have any improvement so far. There is progress, but still no success.

Here are the main things I tried:

For the ACC channels replaced the 0.1 Hz high pass filters by 3Hz high pass and turned off the 1: filter.

Then I tried to incorporate the Z ACC/GUR channels, with some reasonable combination of the others.

The Z axis Guralp and Accelerometers were making OAF unstable, so I put a 0.1 gain in all four of those.

Following the PEM  noise curves Rana has put up, we should probably use

  • two ACC_Y channels (3:0, Notch24, AA32)
  • two GUR_Z channels (filters: 0.1:0, 1:, AA32, gain 0,1)
  • one RANGER_Y, just because it works (0.1:0, 1:, Notch24, AA32)

In the end I tried this combination, it was stable after I reduced the GUR_Z gain, but looked very similar to what we got before, no improvement at 5Hz or 0.5Hz. But there was a stable hint of better performance at > 40Hz.

Possibly we need to increase the GUR_Z gain (but not 1) and try to use ACC_Z channels also. Since we can not handle many channels, possibly using one GUR_Z and one ACC_Z would be worth checking.

  2558   Tue Feb 2 10:38:30 2010 josephbUpdateComputersMegatron BO test

Last night, I connected megatron's BO board to the analog dewhitening board.  However, I was unable to lock the y arm (although once I disconnected the cable and reconnected it back the xy220 the yarm did lock).

So either A) I've got the wrong cable, or B) I've got the wrong logic being sent to the analog dewhitening filters.

During testing, I ran into an odd continuous on/off cycle on one of the side filer modules (on megatron).  Turns out I had forgotten to use a ground input to the control filer bank (which allows you to both set switches as well as read them out), and it was reading a random variable.  Grounding it in the model fixed the problem (after re-making).

 

 

  2561   Tue Feb 2 16:10:09 2010 steveUpdatePEMconstruction progress next door

CES construction is progressing. The 40m suspensions are bearing well.

atm1, PEM  vs sus plots of 120 days

atm2, big pool walls are in place, ~10 ft east of south arm

atm3, 10 ft east of ITMY

atm4, ~60 ft east of ITMY

atm5, cold weather effect of N2 evaporator tower

Attachment 1: pem120d.jpg
pem120d.jpg
Attachment 2: 02022010.JPG
02022010.JPG
Attachment 3: 02022010b.JPG
02022010b.JPG
Attachment 4: 02022010c.JPG
02022010c.JPG
Attachment 5: icewall.JPG
icewall.JPG
  2562   Tue Feb 2 18:15:47 2010 AlbertoUpdateelogElog restarted it

 Zach made me notice that the elog had crashed earlier on this afternoon. 

I just restarted it with the restarting script.

Instructions on how to run the last one are now in the wiki page. Look on the "How To" section, under "How to restart the elog".

  2563   Tue Feb 2 22:39:12 2010 JenneUpdatePSLIFO isn't playing nice tonight

[Jenne, Kiwamu]

It's been an iffy last few hours here at the 40m.  Kiwamu, Koji and I were all sitting at our desks, and the computers / RFM network decided to crash.  We brought all of the computers back, but now the RefCav and PMC don't want to lock.  I'm a wee bit confused by this.  Both Kiwamu and I have given it a shot, and we can each get the ref cav to sit and flash, but we can't catch it.  Also, when I bring the PMC slider rail to rail, we see no change in the PMC refl camera.  Since c1psl had been finicky coming back the first time, I tried soft rebooting, and then keying the crate again, but the symptoms remained the same.  Also, I tried burt restoring to several different times in the last few days, to see if that helped.  It didn't.  I did notice that MC2 was unhappy, which was a result of the burtrestores setting the MCL filters as if the cavity were locked, so I manually ran mcdown.  Also, the MC autolocker script had died, so Kiwamu brought it back to life.

Since we've spent an hour on trying to relock the PSL cavities (the descriptive word I'm going to suggest for us is persistent, not losers), we're giving up in favor of waiting for expert advice in the morning.  I suppose there's something obvious that we're missing, but we haven't found it yet......

  2564   Wed Feb 3 01:17:19 2010 KojiUpdatePSLIFO isn't playing nice tonight

I checked the situation from my home and the problem was solved.

The main problem was undefined state of the autolocker and the strange undefined switch states, being associated with the bootfest and burtrestore.

- MC UP/DOWN status shows it was up and down. So I ran scripts/MC/mcup and scripts/MC/mcdown. These cleared the MC autolocker status.

- I had a problem handling the FSS. After mcup/mcdown above, I randomly pushed the "enable/disable" buttons and others, and with some reason, it recovered the handling. Actually it acquired the lock autonomously. Kiwamu may have also been working on it at the same time???

- Then, I checked the PSL loop. I disconnected the loop by pushing the "test" button. The DC slider changes the PZT voltage only 0~+24V. This is totally strange and I started pushing the buttons randomly. As soon as I pushed the  "BLANK"/"NORMAL" button, the PZT output got back under the control.

- Then I locked the PMC, MZ, and MC as usual.

Alberto: You must be careful as the modulations were restored.

Quote:

[Jenne, Kiwamu]

It's been an iffy last few hours here at the 40m.  Kiwamu, Koji and I were all sitting at our desks, and the computers / RFM network decided to crash.  We brought all of the computers back, but now the RefCav and PMC don't want to lock.  I'm a wee bit confused by this.  Both Kiwamu and I have given it a shot, and we can each get the ref cav to sit and flash, but we can't catch it.  Also, when I bring the PMC slider rail to rail, we see no change in the PMC refl camera.  Since c1psl had been finicky coming back the first time, I tried soft rebooting, and then keying the crate again, but the symptoms remained the same.  Also, I tried burt restoring to several different times in the last few days, to see if that helped.  It didn't.  I did notice that MC2 was unhappy, which was a result of the burtrestores setting the MCL filters as if the cavity were locked, so I manually ran mcdown.  Also, the MC autolocker script had died, so Kiwamu brought it back to life.

Since we've spent an hour on trying to relock the PSL cavities (the descriptive word I'm going to suggest for us is persistent, not losers), we're giving up in favor of waiting for expert advice in the morning.  I suppose there's something obvious that we're missing, but we haven't found it yet......

 

  2565   Wed Feb 3 07:57:01 2010 steveUpdatePSLPMC transmission is low

The low PMC transmission alarm was on this morning. The PMC alignment needs a touch up.

Attachment 1: pmct40d.jpg
pmct40d.jpg
  2566   Wed Feb 3 09:01:42 2010 robUpdateloreIFO isn't playing nice tonight

Quote:

I checked the situation from my home and the problem was solved.

The main problem was undefined state of the autolocker and the strange undefined switch states, being associated with the bootfest and burtrestore.

- MC UP/DOWN status shows it was up and down. So I ran scripts/MC/mcup and scripts/MC/mcdown. These cleared the MC autolocker status.

- I had a problem handling the FSS. After mcup/mcdown above, I randomly pushed the "enable/disable" buttons and others, and with some reason, it recovered the handling. Actually it acquired the lock autonomously. Kiwamu may have also been working on it at the same time???

- Then, I checked the PSL loop. I disconnected the loop by pushing the "test" button. The DC slider changes the PZT voltage only 0~+24V. This is totally strange and I started pushing the buttons randomly. As soon as I pushed the  "BLANK"/"NORMAL" button, the PZT output got back under the control.

- Then I locked the PMC, MZ, and MC as usual.

Alberto: You must be careful as the modulations were restored.

Quote:

[Jenne, Kiwamu]

It's been an iffy last few hours here at the 40m.  Kiwamu, Koji and I were all sitting at our desks, and the computers / RFM network decided to crash.  We brought all of the computers back, but now the RefCav and PMC don't want to lock.  I'm a wee bit confused by this.  Both Kiwamu and I have given it a shot, and we can each get the ref cav to sit and flash, but we can't catch it.  Also, when I bring the PMC slider rail to rail, we see no change in the PMC refl camera.  Since c1psl had been finicky coming back the first time, I tried soft rebooting, and then keying the crate again, but the symptoms remained the same.  Also, I tried burt restoring to several different times in the last few days, to see if that helped.  It didn't.  I did notice that MC2 was unhappy, which was a result of the burtrestores setting the MCL filters as if the cavity were locked, so I manually ran mcdown.  Also, the MC autolocker script had died, so Kiwamu brought it back to life.

Since we've spent an hour on trying to relock the PSL cavities (the descriptive word I'm going to suggest for us is persistent, not losers), we're giving up in favor of waiting for expert advice in the morning.  I suppose there's something obvious that we're missing, but we haven't found it yet......

 

 

This is a (sort of) known problem with the EPICS computers: it's generally called the 'sticky slider' problem, but of course it applies to buttons as well.  It happens after a reboot, when the MEDM control/readback values don't match the actual applied voltages.  The solution (so far) is just to `twiddle' the problematic sliders/button.  There's a script somewhere called slider_twiddle that does this, but I don't remember if it has PSL stuff in it.  A better solution is probably to have an individual slider twiddle script for each target machine, and add the running of that script to the reboot ritual in the wiki.

  2567   Wed Feb 3 10:46:12 2010 AlbertoUpdateelogelog restarted

 Again, this morning Zach told me that the elog had crashed while he was trying to post an entry.

I just restarted it.

  2569   Thu Feb 4 00:59:52 2010 ranaUpdateelogelog restarted

 I restarted the ELOG on NODUS just now. Our attempt to set up error logging worked - it turns out ELOG was choking on the .ps file attachment.

So for the near future: NO MORE .PS files! Use PDF - move into the 20th century at least.

matlab can directly make either PNG or PDF files for you, you can also use various other conversion tools on the web.

Of course, it would be nice if nodus could handle .ps, but its a Solaris machine and I don't feel like debugging this. Eventually, we'll give him away and make the new nodus a Linux box, but that day is not today.

  2570   Thu Feb 4 12:29:04 2010 josephbUpdateComputersMartian IP switch over notes

What is the change:

We will be moving the 131.215.113.XXX ip addresses of the martian network over to a 192.168.XXX.YYY scheme.

What will users notice:

Computer names (i.e. linux1, scipe25/c1dcuepics) will not change.  The domain name martian, will not change (i.e. linux1.martian.).  What will change is the underlying IP address associated with the host names.  Linux1 will no longer be 131.215.113.20 but something like 192.168.0.20.  If everything is done properly, that should be it.  There should be no impact or need to change anything in EPICS for example.  However, if there are custom scripts with hard coded IP addresses rather than hostnames, those would need to be updated, if they exist.

What needs to be done:

Each computer and router will need to either be accessed remotely, or directly, and the configuration files controlling the IP address (and/or dns lookup locations) be modified.  Then it needs to be rebooted so the configuration changes take effect. I'll be making an updated list of computers this week (tracked down via their physical ethernet cables), and next week, probably on Thursday, and then we simply go down the list one by one.

LINUX

For a linux machine, this means checking the /etc/hosts file and making sure it doesn't have old information.  It should look like:

127.0.0.1               localhost.localdomain localhost
::1             localhost6.localdomain6 localhost6

Then change the /etc/sysconfig/network-scripts/ifcfg-eth0 file (or ethX file depending on the ethernet card in question).  The IPADDR, NETWORK, and GATEWAY lines will need to be changed.  You can change the hostname (although I don't plan on it) by modifying the /etc/sysconfig/network file.

The /etc/resolv.conf file will need to be updated with the new DNS server location (i.e. 131.215.113.20 to 192.168.0.20 for example).

SOLARIS

Simlarly to linux, the /etc/hosts file will need to be updated and/or simplified.  The /etc/defaultrouter file will need to be updated to the new router ip.  /etc/defaultdomain will need to be updated.  The /etc/resolv.conf will need to be updated with the new dns server.

vxWorks

Looking at the vxWorks machines, the command bootChange can be used to view or edit the IP configuration.

The following is an example from c1iscey.

-> bootChange

'.' = clear field;  '-' = go to previous field;  ^D = quit

boot device          : eeE0
processor number     : 0
host name            : linux1
file name            : /cvs/cds/vw/pIII_7751/vxWorks
inet on ethernet (e) : 131.215.113.79:ffffff00
inet on backplane (b):
host inet (h)        : 131.215.113.20
gateway inet (g)     :
user (u)             : controls
ftp password (pw) (blank = use rsh):
flags (f)            : 0x0
target name (tn)     : c1iscey
startup script (s)   :
other (o)            :

value = 0 = 0x0

By updating the the host (name of machine where its mounting /cvs/cds from - i.e. linux1), inet on ethernet (the IP of c1iscey) and host inet (linux1's ip address), we should be able to change all the vxWorks machines.

LINUX1

The DNS server running on linux1 will need to be updated with the new IPs and domain information.  The host file on linux1 will also need to be updated for all the new IP addresses as well.

This will need to be handled carefully as the last time I tried getting away without the host file on linux1, it broke NFS mounting from other machines.  However, as long as the host on linux1 is kept in sync with the dns server files everything should work.

  2571   Fri Feb 5 00:52:55 2010 SanjitUpdateAdaptive FilteringOAF at 0.1-1.0 Hz

 

At 0.1-1.0Hz, there is some coherence between MC_L and RANGER_Y & GUR_Y, see the first figure. Also GUR_Z has low noise there. So I used all five of them, increased the gains of GUR_Z from 0.1 to 0.5. Some improvement near 0.5Hz. We possibly can not do any better with these PEM measurement, as the coherence of the adapted error signal and the PEM channels is almost zero, see the second figure. May be we need to think about placing the seismometers at different places/orientations.

However, there is lot more scope at higher frequencies, lot of coherence at 5-100Hz.

 

Attachment 1: OAF_04FEB2010_noOAF.png
OAF_04FEB2010_noOAF.png
Attachment 2: OAF_04FEB2010.png
OAF_04FEB2010.png
  2572   Fri Feb 5 01:04:58 2010 SanjitUpdateAdaptive FilteringOAF at > 5Hz

 

There is lot of coherence between the error signal and PEM channels at 5-100Hz. We had been applying a 1Hz low pass filter to all the GUR and RANGER channels for stability. I turned those off and OAF still works with mu=0.0025, this will give us some more freedom. Kind of annoying for testing though, it takes about 45min to adapt!

In any case, there is no significant improvement at high frequencies as compared to our usual OAF performance. Also, the low frequency improvement (see previous e-log) is lost in this set up. I think, we have to adjust the number of taps and channels to do better at high frequencies. Also, delay can be important at these frequencies, needs some testing.

 

Attachment 1: OAF_04FEB2010_highFreq.png
OAF_04FEB2010_highFreq.png
  2574   Fri Feb 5 14:31:46 2010 JenneUpdateSUS2 SOS towers assembled

[Jenne, Kiwamu]

The 2 SOS towers for the ITMs have been assembled, and are on the flow bench in the cleanroom.  Next up is to glue magnets, dumbells, guiderods and wire standoffs to the optics, then actually hang the mirrors.

DSC_1156.JPG

  2575   Sat Feb 6 00:10:08 2010 SanjitUpdateAdaptive FilteringOAF at > 5Hz

 

Did some more test to get better performance at higher frequencies.

Increased # taps to 4000 and reduced downsampling to 4, without changing the AA32 filters, from CORR, EMPH and the matching ADPT channels. But for testing I turned off AA32 from the input PEM channels. So that high frequency still gets blocked at CORR, but the adaptive filters have access to higher frequencies. Once we fix some reasonable downsampling, we should create corresponding AA filters.

I used only two channels, RANGER/GUR2_Y and GUR1_Z, and basically they had only one filter 0.1:0

This set up gave little better performance (more reduction at more frequencies), at some point even the 16HZ peak was reduced by a factor of 3. The 24Hz peak was a bit unstable, but became stable after I removed the Notch24 filters from PEM channels, to ensure that OAF is aware of those lines. There was some improvement also at the 24Hz peak.

 

  2576   Mon Feb 8 14:13:03 2010 AlbertoUpdateABSLPLL Characterization

Lately I've been trying to improve the PLL for the AbsL experiment so that it could handle larger frequency steps and thus speed up the cavity scan.

The maximum frequency step that the PLL could handle withouth losing lock is given by the DC gain of the PLL. This is the product of the mixer's gain factor K [rad/V ], of the laser's calibration C [Hz/V] and of the PLL filter DC gain F(0).

I measured these quantities: K=0.226 V/rad; C=8.3e6 Hz/V and F(0)=28.7dB=21.5. The max frequency step should be Delta_f_max = 6.4MHz.

Although in reality the PLL can't handle more than a 10 KHz step. There's probably some other effect that I'm not.

I'm attaching here plots of the PLL Open Loop Gain, of the PLL filter and of a spectra of the error point measured in different circumstances.

I don't have much time to explain here how I took all those measurements. After I fix the problem, I'm going to go go through those details in an elog entry.

Does anyone have any suggestion about what, in principle, might be limiting the frequency step?

I already made sure that both cables going to the mixer (the cable with the beat signal coming from the photodiode and the cable with the LO signal coming from the Marconi) had the same length. Although ideally, for phase locking, I would still need 90 degrees of phase shift between the mixing signals, over the entire frequency range for which I do the cavity scan. By now the 90 degrees are not guaranteed.

Also, I have a boost that adds another 20 dB at DC to the PLL's filter. Although it doesn't change anything. In fact, as said above calculating the frequency step, the PLL should be able to handle 100KHz steps, as I would want the PLL to do.

Attachment 1: 2010-02-08_Old_PDH_Box_Filter_TF_gain_knob_0_Boost_OFF.png
2010-02-08_Old_PDH_Box_Filter_TF_gain_knob_0_Boost_OFF.png
Attachment 2: 2010-02-08_PLL_OLG_gain_knob_0_Boost_OFF.png
2010-02-08_PLL_OLG_gain_knob_0_Boost_OFF.png
Attachment 3: 2010-02-08_PLL_Noise_Budget.png
2010-02-08_PLL_Noise_Budget.png
  2577   Mon Feb 8 14:56:17 2010 AlbertoUpdateABSLSuddenly a much better alignment of PRC

I just aligned PRM and locked PRC and I noticed that SPOB is much higehr than it used to be. It's now about 1800, vs 1200 than it used to be last week.

Isn't anyone related to that? If so, may I please know how he/she did it?

  2578   Mon Feb 8 15:01:46 2010 robUpdateABSLSuddenly a much better alignment of PRC

Quote:

I just aligned PRM and locked PRC and I noticed that SPOB is much higehr than it used to be. It's now about 1800, vs 1200 than it used to be last week.

Isn't anyone related to that? If so, may I please know how he/she did it?

 oops, my bad.  I cranked the 33MHz modulation depth and forgot to put it back.  The slider should go back to around 3. 

  2579   Mon Feb 8 15:41:51 2010 AlbertoUpdateABSLSuddenly a much better alignment of PRC

Quote:

Quote:

I just aligned PRM and locked PRC and I noticed that SPOB is much higehr than it used to be. It's now about 1800, vs 1200 than it used to be last week.

Isn't anyone related to that? If so, may I please know how he/she did it?

 oops, my bad.  I cranked the 33MHz modulation depth and forgot to put it back.  The slider should go back to around 3. 

 I was actually hoping that the alignment got better.

  2580   Mon Feb 8 17:00:36 2010 josephbUpdateComputersMegatron ETMY model updated (tst.mdl)

I've added the control logic for the outputs going to the Contec Digital Output board.  This includes outputs from the QPD filters (2 filters per quadrant, 8 in total), as well as outputs going to the coil input sensor whitening.

At this point, the ETMY controls should have everything the end station FE normally does.  I'm hoping to do some testing tomorrow afternoon with this with a fully locked IFO.

  2581   Tue Feb 9 09:07:06 2010 AlbertoUpdateABSLPLL Characterization

Quote:

Lately I've been trying to improve the PLL for the AbsL experiment so that it could handle larger frequency steps and thus speed up the cavity scan.

The maximum frequency step that the PLL could handle withouth losing lock is given by the DC gain of the PLL. This is the product of the mixer's gain factor K [rad/V ], of the laser's calibration C [Hz/V] and of the PLL filter DC gain F(0).

I measured these quantities: K=0.226 V/rad; C=8.3e6 Hz/V and F(0)=28.7dB=21.5. The max frequency step should be Delta_f_max = 6.4MHz.

Although in reality the PLL can't handle more than a 10 KHz step. There's probably some other effect that I'm not.

I'm attaching here plots of the PLL Open Loop Gain, of the PLL filter and of a spectra of the error point measured in different circumstances.

I don't have much time to explain here how I took all those measurements. After I fix the problem, I'm going to go go through those details in an elog entry.

Does anyone have any suggestion about what, in principle, might be limiting the frequency step?

I already made sure that both cables going to the mixer (the cable with the beat signal coming from the photodiode and the cable with the LO signal coming from the Marconi) had the same length. Although ideally, for phase locking, I would still need 90 degrees of phase shift between the mixing signals, over the entire frequency range for which I do the cavity scan. By now the 90 degrees are not guaranteed.

Also, I have a boost that adds another 20 dB at DC to the PLL's filter. Although it doesn't change anything. In fact, as said above calculating the frequency step, the PLL should be able to handle 100KHz steps, as I would want the PLL to do.

I might have found the problem with the PLL that was preventing me from scanning the frequencies by 100KHz steps. A dumb flimsy soldering in the circuit was making the PLL unstable.

After I fixed that problem and also after writing a cleverer data acquisition script in Python,  I was able to scan continuosly the range 10-200MHz in about 20min (versus the almost 1.5-2 hrs that I could do previously). I'm attaching the results to this entry.

The 'smears' on the right side of the resonance at ~33MHz, are due to the PSL's sideband. I think I know how to fix that.

As you can see, the problem is that the model for the cavity transmission still does not match very well the data. As a result, the error on the cavity length is too big (~> 10 cm - I'd like to have 1mm).

Anyway, that was only my first attempt of scanning. I'm going to repeat the measurement today too and see if I can come out better. If not, than I have to rethink the model I've been using to fit.

Attachment 1: 2010-02-08_PRCtransmissivity_EntireFreqRange_VsFit.png
2010-02-08_PRCtransmissivity_EntireFreqRange_VsFit.png
  2582   Tue Feb 9 10:10:58 2010 AlbertoUpdateABSLback to analog

I want to try to do the measurement with the network analyzer used as local oscillator, instead of the Marconis that I'm using now. Tha could give me better noise rejection. It would also give me information about the phase.

Also I wouldn't dislike abandoning the GPIB interfaces to acquire data.

  2586   Wed Feb 10 17:28:02 2010 kiwamuUpdateElectronicstriple resonant EOM ---- preliminary result

I have made a prototype circuit of the triple resonant EOM.

The attached is the measured optical response of the system.

The measured gains at the resonances are 8.6, 0.6 and 7.7 for 11MHz, 29.5MHz and 55MHz respectively.

I successfully got nice peaks at 11MHz and 55MHz. In addition resultant optical response is well matched with the predicted curve from the measured impedance.

However there is a difference from calculated response (see past entry) (i.e. more gains were expected)

Especially for the resonance of 29.5MHz, it was calculated to have gain of 10, however it's now 0.6. Therefore there must a big loss electrically around 29.5MHz.

I am going to re-analyze the impedance and model the performance in order to see what is going on.

Attachment 1: mod_depth.png
mod_depth.png
  2587   Wed Feb 10 23:15:37 2010 KojiUpdateElectronicstriple resonant EOM ---- preliminary result

Hey, this looks nice, but can you provide us the comparison of rad/V with the resonant EOM of New Focus?

Quote:

I have made a prototype circuit of the triple resonant EOM.

The attached is the measured optical response of the system.

The measured gains at the resonances are 8.6, 0.6 and 7.7 for 11MHz, 29.5MHz and 55MHz respectively.

I successfully got nice peaks at 11MHz and 55MHz. In addition resultant optical response is well matched with the predicted curve from the measured impedance.

However there is a difference from calculated response (see past entry) (i.e. more gains were expected)

Especially for the resonance of 29.5MHz, it was calculated to have gain of 10, however it's now 0.6. Therefore there must a big loss electrically around 29.5MHz.

I am going to re-analyze the impedance and model the performance in order to see what is going on.

 

  2590   Thu Feb 11 16:52:53 2010 kiwamuUpdateElectronicstriple resonant EOM ---- preliminary result

The commercial resonant EOM of New Focus has the modulation efficiency of 50-150mrad/Vrms. ( This number is only true for those EOM made from KTP such as model4063 and model4463 )

Our triple-resonant EOM (made from KTP as well) has a 90mrad/Vrms and 80mrad/Vrms at the reosonances of 11MHz and 55MHz respectively.

Therefore our EOM is as good as those of company-made so that we can establish a new EOM company

Quote:

Hey, this looks nice, but can you provide us the comparison of rad/V with the resonant EOM of New Focus?

Quote:

I have made a prototype circuit of the triple resonant EOM.

The attached is the measured optical response of the system.

The measured gains at the resonances are 8.6, 0.6 and 7.7 for 11MHz, 29.5MHz and 55MHz respectively.

I successfully got nice peaks at 11MHz and 55MHz. In addition resultant optical response is well matched with the predicted curve from the measured impedance.

However there is a difference from calculated response (see past entry) (i.e. more gains were expected)

Especially for the resonance of 29.5MHz, it was calculated to have gain of 10, however it's now 0.6. Therefore there must a big loss electrically around 29.5MHz.

I am going to re-analyze the impedance and model the performance in order to see what is going on.

 

 

  2591   Thu Feb 11 18:33:54 2010 josephb, alexUpdateComputersStatus of the IP change over

A few machines have still not been changed over, including a few laptops, mafalda, ottavia, and c0rga.

All the front ends have been changed over.

fb40m died during a reboot and was replaced with a spare Sun blade 1000 that Larry had.  We had to swap in our old hard drive and memory.

All the front ends, belladonna, aldabella, and the control room machines have been switched over. Nodus was changed over after we realized we hosed the elog and svn by switching linux1's IP.

At this point, 90% of the machines seem to be working, although c0daqawg seems to be having some issues with its startup.cmd code.

  2593   Thu Feb 11 19:20:44 2010 ranaUpdateComputersStatus of the IP change over

After Joe left:

  1. Turned on op440m and returned him his keyboard and mouse.
  2. Damped MC2.
  3. Opened PSL shutter - locked PMC, FSS,
  4. Started StripTool displays on op540m.
  5. op340m doesn't respond to ping from anyone.
  6. started FSS  SLOW and RCPID scripts on op540 - need to kill and restart on op430m.
  7. ASS wouldn't come up - it doesn't know who linux1 is.
  8. MC autolocker wouldn't run on op540m because of a perl module issue, started it on op440m - it needs to be killed and restarted on op430m.
  9. probably mafalda, linux2, and op430m need some attention - they are all in the same rack.

As of 7:18 PM, the MC is locked and the PSL seems normal + all suspensions are damped and the ELOG is back up as well as the SVN.

  2594   Fri Feb 12 11:44:11 2010 josephbUpdateComputersStatus of the IP change over

Quote:

After Joe left:

  1. Turned on op440m and returned him his keyboard and mouse.
  2. Damped MC2.
  3. Opened PSL shutter - locked PMC, FSS,
  4. Started StripTool displays on op540m.
  5. op340m doesn't respond to ping from anyone.
  6. started FSS  SLOW and RCPID scripts on op540 - need to kill and restart on op430m.
  7. ASS wouldn't come up - it doesn't know who linux1 is.
  8. MC autolocker wouldn't run on op540m because of a perl module issue, started it on op440m - it needs to be killed and restarted on op430m.
  9. probably mafalda, linux2, and op430m need some attention - they are all in the same rack.

As of 7:18 PM, the MC is locked and the PSL seems normal + all suspensions are damped and the ELOG is back up as well as the SVN.

5) op340m has had its hosts table and other network files updated.  I also removed its outdated hosts.deny file which was causing some issues with ssh.

6) On op340m I started FSSSlowServo, with "nohup ./FSSSlowServo", after killing it on op540m.

I also kill RCthermalPID.pl, and started with "nohup ./RCthermalPID.pl" on op540m.

7) c1ass is fixed now.  There was a typo in the resolv.conf file (namerserver -> nameserver) which has been fixed.  It is now using the DNS server running on linux1 for all its host name needs.

8) I killed the autlockMCmain40m process running on op440m, modified the script to run on op340m, logged into op340m, went to /cvs/cds/caltech/scripts/MC and ran nohup ./autolockMCmain40m

9) Linux2 does not look like it has not been connected for awhile and its wasn't connected when we started the IP change over yesterday.  Is it supposed to still be in use?  If so, I can hook it up fairly easily.  op340m, as noted earlier, has been switched over.  Mafalda has been switched over.

10) c0rga has now been switched over. 

11) aldabella, the vacuum laptop has had its starting environment variables tweaked (in the /home/controls/.cshrc file) so that it looks on the 192.168.113 network instead of the 131.215.113.  This should mean Steve will not have any more trouble starting up his vacuum control screen.

12) Ottavia has been switched over.

13) At this time, only the GPIB devices and a few laptops remain to get switched over.

  2595   Fri Feb 12 11:56:02 2010 josephbUpdateComputersNodus slow ssh fixed

Koji pointed out that logging into Nodus was being abnormally slow.  I tracked it down to the fact we had forgotten to update the address for the DNS server running on linux1 in the resolv.conf file on nodus.  Basically it was looking for a DNS server which didn't exit, and thus was timing out before going to the next one.  SSHing into nodus should be more responsive.

  2596   Fri Feb 12 13:15:41 2010 kiwamuUpdateElectronicstriple resonant EOM --- liniaryity test

I have measured the linearity of our triple resonant EOM (i.e. modulation depth versus applied voltage)

The attached figure is the measured modulation depth as a function of the applied voltage.

The linear behavior is shown below 4Vrms, this is good.

Then it is  slowly saturated as the applied voltage goes up above 4Vrms.

However for the resonance of 29.5MHz, it is difficult to measure below 7Vrms because of the small modulation depth.

Our triple resonant EOM looks healthy

 - - - - result from fitting - - -

11MHz: 91mrad/Vrms+2.0mrad

29.5MHz: 4.6mrad/Vrms+6.2mrad

55MHz:82mrad/Vrms+1.0mrad

Attachment 1: linearity_edit.png
linearity_edit.png
  2597   Fri Feb 12 13:56:16 2010 josephbUpdateComputersFinishing touches on IP switch over

The GPIB interfaces have been updated to the new 192.168.113.xxx addresses, with Alberto's help.

Spare ethernet cables have been moved into a cabinet halfway down the x-arm.

The illuminators have a white V error on the alarm handler, but I'm not sure why.  I can turn them on and off using the video screen controls (except for the x arm, which has no computer control, just walk out and turn it on).

There's a laptop or two I haven't tracked down yet, but that should be it on IPs. 

At some point, a find and replace on 131.215.xxx.yyy addresses to 192.168.xxx.yyy should be done on the wiki.  I also need to generate an up to date ethernet IP spreadsheet and post it to the wiki.

 

  2599   Fri Feb 12 15:59:16 2010 josephbUpdateComputersTestpoints not working

Non-testpoint channels seem to be working in data viewer, however testpoints are not.  The tpman process is not running on fb40m.  My rudimentary attempts to start it have failed. 

# /usr/controls/tpman &
13929
# VMIC RFM 5565 (0) found, mapped at 0x2868c90
VMIC RFM 5579 (1) found, mapped at 0x2868c90
Could not open 5565 reflective memory in /dev/daqd-rfm1
16 kHz system
Spawn testpoint manager
no test point service registered
Test point manager startup failed; -1

It looks like it may be an issue with the reflected memory (although the cables are plugged in and I see the correct lights lit on the RFM card in back of fb40m.)

The fact that this is a RFM error is confirmed by /usr/install/rfm2g_solaris/vmipci/sw-rfm2g-abc-005/util/diag/rfm2g_util and entering 3 (which should be the device number).

Interestingly, the device number 4 works, and appears to be the correct RFM network (i.e. changing ETMY lscPos offset changes to the corresponding value in memory).

So, my theory is that when Alex put the cards back in, the device number (PCI slot location?) was changed, and now the tpman code doesn't know where to look for it.

Edit: Doesn't look like PCI slot location is it, given there's 4 slots and its in #3 currently (or 2 I suppose, depending on which way you count).  Neither seems much the number 4.  So I don't know how that device number gets set.

 

 

  2601   Fri Feb 12 18:58:46 2010 kiwamuUpdateGreen Lockingtake some optics away from the ETM end table

In the last two days Steve and I took some optics away from the both ETM end table.

This is because we need an enough space to set up the green locking stuff into the end table, and also need to know how much space is available.

Optics we took away are : Alberto's RF stuff, fiber stuff and some optics obviously not in used.

The picture taken after the removing is attached. Attachment1:ETMX, Attachment2:ETMY

And the pictures taken before the removing are on the wiki, so you can check how they are changed.

http://lhocds.ligo-wa.caltech.edu:8000/40m/Optical_Tables

Attachment 1: DSC_1164.JPG
DSC_1164.JPG
Attachment 2: DSC_1172.JPG
DSC_1172.JPG
  2602   Sat Feb 13 13:21:53 2010 KojiUpdateElectronicstriple resonant EOM --- liniaryity test

Looks good. I just thought of the idea that we also can use Alberto's PLL setup to sense the modulation with more sensitivity.  ;-)

Quote:

I have measured the linearity of our triple resonant EOM (i.e. modulation depth versus applied voltage)

The attached figure is the measured modulation depth as a function of the applied voltage.

The linear behavior is shown below 4Vrms, this is good.

Then it is  slowly saturated as the applied voltage goes up above 4Vrms.

However for the resonance of 29.5MHz, it is difficult to measure below 7Vrms because of the small modulation depth.

Our triple resonant EOM looks healthy

 - - - - result from fitting - - -

11MHz: 910mrad/Vrms+20mrad

29.5MHz: 46mrad/Vrms+6.2mrad

55MHz:820mrad/Vrms+10mrad

 

  2603   Sat Feb 13 18:58:31 2010 josephb, alexUpdateComputersfb40m testpoints fixed

I received an e-mail from Alex indicating he found the testpoint problem and fixed it today:

Quote from Alex: "After we swapped the frame builder computer it has reconfigured all device files and I needed to create some symlinks on /dev/ to make tpman work again. I test the testpoints and they do work now."

 

  2604   Tue Feb 16 09:51:22 2010 AlbertoUpdateGreen Lockingtake some optics away from the ETM end table

Quote:

In the last two days Steve and I took some optics away from the both ETM end table.

This is because we need an enough space to set up the green locking stuff into the end table, and also need to know how much space is available.

Optics we took away are : Alberto's RF stuff, fiber stuff and some optics obviously not in used.

The picture taken after the removing is attached. Attachment1:ETMX, Attachment2:ETMY

And the pictures taken before the removing are on the wiki, so you can check how they are changed.

http://lhocds.ligo-wa.caltech.edu:8000/40m/Optical_Tables

The PD Kiwamu removed from the Y table was TRY, which we still need.

My bad if he took that. By mistake I told him that was the one I installed on the table for the length measurement and we didn't need it anymore.

I'm going to ask Kiwamu if he can kindly put it back.

  2606   Tue Feb 16 11:12:51 2010 kiwamuUpdateGreen LockingRe:take some optics away from the ETM end table

Quote:

Quote:

In the last two days Steve and I took some optics away from the both ETM end table.

This is because we need an enough space to set up the green locking stuff into the end table, and also need to know how much space is available.

Optics we took away are : Alberto's RF stuff, fiber stuff and some optics obviously not in used.

The picture taken after the removing is attached. Attachment1:ETMX, Attachment2:ETMY

And the pictures taken before the removing are on the wiki, so you can check how they are changed.

http://lhocds.ligo-wa.caltech.edu:8000/40m/Optical_Tables

The PD Kiwamu removed from the Y table was TRY, which we still need.

My bad if he took that. By mistake I told him that was the one I installed on the table for the length measurement and we didn't need it anymore.

I'm going to ask Kiwamu if he can kindly put it back.

 I am going to put the PD back to the Y end table in this afternoon.

  2609   Tue Feb 16 16:24:30 2010 kiwamuUpdateGreen LockingRe:Re:take some optics away from the ETM end table

I put the TRY_PD back to the end table and aligned it. Now it seems to be working well.

Quote:

The PD Kiwamu removed from the Y table was TRY, which we still need.

My bad if he took that. By mistake I told him that was the one I installed on the table for the length measurement and we didn't need it anymore.

I'm going to ask Kiwamu if he can kindly put it back.

 I am going to put the PD back to the Y end table in this afternoon.

 

  2610   Wed Feb 17 12:45:19 2010 josephbUpdateComputersUpdated Megatron and its firewall

I updated the IP address on the Cisco Linksys wireless N router, which we're using to keep megatron separated from the rest of the network.  I then went in and updated megatrons resolv.conf and host files.  It is now possible to ssh into megatron again from the control machines.

  2611   Wed Feb 17 19:36:05 2010 KojiUpdateCOCArm visibility

I have measured the arm visibilities.
I did not see any change since the last wiping. Our vacuum is not contaminating the cavity in the time scale of 2 months.

It is very good.


Arm visibility measurement ~ latest (Feb. 17, 2010)

X Arm: 0.898 +/- 0.003
Y Arm: 0.892 +/- 0.006

Arm visibility measurement after the vent (Dec. 14, 2009)

X Arm: 0.897 +/- 0.005
Y Arm: 0.893 +/- 0.004

Arm visibility measurement before the vent (Nov 10, 2009)

X Arm: 0.875 +/- 0.005
Y Arm:
0.869 +/- 0.006

  2614   Fri Feb 19 00:31:17 2010 JenneUpdateCOCNew ITMX guiderods glued

[Jenne, Kiwamu, with moral support from Koji, and loads of advice from Steve and Bob]

New upgrade ITMX (ITMU03) has it's guiderod & standoff glued on, as step 1 toward hanging the ITMs.

Procedure:

1. Make sure you have everything ready.  This is long and complicated, but not really worth detail here.  Follow instructions in E970037 (SOS Assembly Spec), and get all the stuff in there.

2. Set optic in a 'ring stand', of which Bob has many, of many different sizes. They are cleaned and baked, and in the cleanroom cupboard on the bottom just behind the door. We used the one for 3" optics.  This lets you sit the optic down, and it only rests on the bevel on the outside, so no coated surface touches anything.

3. Drag wipe the first surface of the optic, using Isopropyl Alcohol.  We used the little syringes that had been cleaned for the Drag Wipe Event which happened in December, and got fresh Iso out of the bottle which was opened in Dec, and put it into a baked glass jar.  The drag wipe procedure was the same as for the December event, except the optic was flat on the bench, in the ring holder.

4. Turn the optic over.

5. Drag wipe the other surface.

6. Align the optic in the guiderod gluing fixture (Step 3 in Section 3.2.1: Applying Guide Rod and Wire Standoff of E970037).

7. Set guiderod and standoff (1 guiderod on one side, 1 standoff on the other, per instructions) against the side of the optic.

8.a.  Use a microscope mounted on a 3-axis micrometer base to help align the guiderod and standoff to the correct places on the optic (Steps 4-5 of Section 3.2.1).  This will be much easier now that we've done it once, but it took a looooooong time. 

8.b.  We put the optic in 180deg from the way we should, based on the direction of the wedge angle in the upgrade table layout (wedge angle stuff used a "Call a Friend" lifeline.  We talked to Koji.) The instructions say to put the guiderod and standoff "above" the scribe lines in the picture on Page 5 of E970037 - the picture has the arms of the fixture crossing over the scribe lines.  However, to make the optic hang correctly, we needed to put the guiderod and standoff below the scribe lines.  This will be true as long as the arrow scribe line (which marks the skinniest part of the optic, and points to the HR side) is closest to you when the optic is in the fixture, the fixture is laying on the table (not standing up on end) with the micrometer parts to your right.  We should put the other ITM into the fixture the other way, so that the arrow is on the far side, and then we'll glue the guiderod and standoff "above" the scribe lines.  Mostly this will be helpful so that we can glue in exactly the places the instructions want us to.

8.c.  The biggest help was getting a flashlight to help illuminate the scribe lines in the optic while trying to site them in the microscope.  If you don't do this, you're pretty much destined to failure, since the lights in the cleanroom aren't all that bright. 

8.d.  The micrometer mount we were able to find for the microscope has a max travel of 0.5", but the optic is ~1" thick.  To find the center of the optic for Step 5 in the guiderod and standoff alignment we had to measure smaller steps, such as bevel-to-end-of-scribe-line, and length-of-scribe-line then end-of-scribe-line-to-other-bevel.  Thankfully once we found the total thickness and calculated the center, we were able to measure once bevel-to-center. 

9. Apply glue to the guiderod and standoff.  We made sure to put this on the "down" side, which once the optic is hung, will be the top of the little rods.  This matches the instructions as to which side of the rods to apply the glue on.  The instructions do want the glue in the center of the rod though, but since we put the optic in the fixture the wrong way, we couldn't reach the center, so we glued the ends of the rods.  We will probably apply another tiny dab of glue on the center of the rod once it's out of the fixture, perhaps while the magnet assemblies are being glued.

10.  We didn't know if the airbake oven which Bob showed us to speed up the curing of our practice epoxy last night was clean enough for the ITM (he was gone by the time we got to that part), so for safety, we're leaving the optic on the flow bench with a foil tent (the foil is secured so there's no way it can blow and touch the optic).  This means that we'll need the full curing time of the epoxy, not half the time.  Maybe tomorrow he'll let us know that the oven is in fact okay, and we can warm it up for the morning.

  2616   Fri Feb 19 10:18:19 2010 JenneUpdateVACThe P1 vac pressure is almost to 3mTorr

The Vac pressure measured at P1 is at 2.5mTorr.  I expect we'll hit 3mTorr sometime this afternoon, at which point (according to Steve) the interlock will shut the shutter, and we won't have light in the IFO.  Anything which needs to happen with light in the IFO before Monday needs to happen fairly soon.

Attachment 1: VacPressureAlmostShutoffLaser_19Feb2010.png
VacPressureAlmostShutoffLaser_19Feb2010.png
  2617   Fri Feb 19 13:28:44 2010 KojiUpdateGeneralPrep for Power Supply Stop

- ETMX/ETMY oplev paths renewed. The nominal gain for ETMY YAW was reversed as a steering mirror has been put.
- Oplevs/QPDs cenrtered except for the MCT QPD.
- SUS snapshots updated
- QPD/Aligment screenshots taken

40m Wiki: Preparation for power supply stop

Attachment 1: screen_shot.png
screen_shot.png
ELOG V3.1.3-