40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 309 of 335  Not logged in ELOG logo
ID Date Author Type Category Subject
  1329   Fri Feb 20 03:52:23 2009 YoichiUpdateLockingLocking Tonight
Yoichi, Peter

Tonight, we had a problem with the DD hand off.
It failed when the RG filters of MICH for the bounce-roll modes are engaged.
The reason for the failure was that the MICH UGF was too low (~10Hz).
As in the Peter's elog entry, we found that the AS PDs are mis-centered.
Even after we fixed the centering, the MICH UGF was still too low. So we increased the MICH feedback gain by a factor of 10.
The reason for the gain decrease is unknown. It seems almost like the BS coils get weaker.
I checked the UGF of the BS OL loops. These are around 4Hz, so fine. We should check the HWP on the AP table tomorrow.

After the DD hand-off goes ok, the switching of DARM signal from DC to RF failed.
I found that the gain and the polarity of the RF signal were wrong.
AS166 is one of the PDs we found mis-centered (and re-centered). But how can you flip the sign of the signal ?

After this, the cm_step script goes until the activation of the moving zero, but fails when the arm power is increased to 0.7.
Also the ontoMCL script succeeds only 50% of the time.
  1328   Fri Feb 20 01:54:18 2009 KakeruUpdateComputer Scripts / Programstdsdata might have a bug

I found a strange jump of value in my data taken with tdsdata.
I couldn't find same jump in a playback of DataViewer, so I think this is a problem of tdsdata.
Be careful when you use tdsdata!

The attached file is an example of jumped data.
I try to get data with allegra and op440m, and both has same kind of jump.
(A downsampling or interpolation may be wrong.)

Rana said there is a fixed version of tdsdata in some PC, but 64bit linux may not have.
I try it tomorrow.

Attachment 1: jumped_data.png
jumped_data.png
  1327   Thu Feb 19 23:50:31 2009 peteUpdateLockingaligned pd's on AP table

Yoichi, Peter

While continuing our efforts to lock, we noticed the procedure failed at a point it had gotten past last night:  turning on the bounce/roll filters in MICH, PRC, and SRC.  We checked the MICH transfer function and noticed that the unity gain point was ~10 Hz, well below the bounce modes.   We tried increasing the gain but found saturation, and Rob suggested that there could be misalignment on the AP table, which Steve worked on today.  We went out and found two of the PDs (ASDD133 and AS166) to be badly misaligned probably due to a bumped optic upstream.  We re-aligned.

 

 

  1326   Thu Feb 19 22:40:33 2009 KiwamuUpdateElectronicsPSL angle QPD

I checked a broken QPD, which was placed for PSL angle monitor, and finally I cocluded one segment of the quadrant diode was broken.

The broken segment has a offset voltage of -0.7V after 1st I-V amplifier. It means the diode segment has a current offset without any injection of light.

Tomorrow I will check a new QPD for replacement.

Kiwamu IZUMI

 

  1325   Thu Feb 19 16:29:43 2009 YoichiUpdateComputersMartian wireless router bad
The Martian wireless router is dead.
I rebooted it several times, but it hangs up in a minute.
I will ask steve to buy a new one.
  1324   Thu Feb 19 11:51:56 2009 steveUpdateMOPAHTEMP variation is too much
The C1:PSL-MOPA_HTEMP variation is more than 0.5 C daily
Normally this temp stays well within 0.1 C
This 80 days plots shows that we have just entered this unstable region some days ago.
The control room temp set unchanged at 70 F, actual temp at ac-mon 69-70 with occasional peaks at 74 F
 
Water temp at chiller repeatedly around 20.6 C at 8 am
This should be rock solid at 20.00C +- 0.02C
 

 

Attachment 1: 80dhtemp.jpg
80dhtemp.jpg
  1323   Thu Feb 19 04:16:17 2009 YoichiUpdateLSCLocking status
Rob, Yoichi

We checked the CM-MC cross over just before turning off the moving zero.
There was a slight bump in the gain of the MC_L loop at (I believe) the optical spring freq. (~400Hz) just below 0 dB. The phase margin there was very thin.
Removing the moving zero will increase the bump more and make the loop unstable.
Rob suggested to increase the AO gain a bit more.

To see if the AO path is really working, I connected the OUT2 of the MC board to a spare DAQ channel (C1:PEM-OSA_APTEMP).
I confirmed that the PO_DC signal is actually coming to the AO path input of the MC board.
I also hooked up the SR785 to the A excitation channel of the common mode board, so that we can measure the loop gain of the AO path.
After these preparation, the lock acquisition process became somewhat unstable. The ifo loses lock randomly at various places in the lock acquisition steps.
So, as of 4:00 am, I have not gotten a chance to try Rob's suggestion nor the TF measurement with SR785 yet.
I will continue the work tomorrow (i.e. tonight ??).

  1322   Wed Feb 18 21:10:21 2009 ranaUpdateIOOMC Drumhead mode lost again
In early December, Caryn and I noticed that the MC Drumhead mode was visible at the Qmon point of
the MC demod board using a spectrum analyzer and no external excitation of the MC mirrors. We then
started tracking the MC Drumhead modes.

Today I found that it is gone again. It also wasn't there when I looked for it in 2007. Mad

I looked at the MC error point spectrum and it seemed reasonable. Changing the gains in the MZ, ISS, PMC, & FSS
had no good effect on the noise spectrum.

The voltage noise above 10 kHz in the MC error point is increasing like ~f. I think that this means that
the leftover is the noise from the FSS. Below 10 kHz it is the noise of the VCO (10 mHz/rHz).

One possibility is that the high frequency noise changes with the mood of the NPRO. There should be no
frequency noise induced by the decay of the PA diode power. We can do an NPRO SLOW scan to see if there
is some kind of mode hop noise happening.
  1321   Wed Feb 18 21:03:22 2009 ranaUpdateCamerasETMY Camera work not elogged!

The control room video is showing us a false ETMY image. Who worked on the ETMY camera or video today??!!

  1320   Wed Feb 18 19:13:20 2009 ranaConfigurationComputersSVN & MEDM & old medm files
Allegra had a 2 year old version of SVN installed and CentOS (yum) couldn't upgrade it, so I did an 'svn remove subversion'
and then a 'svn install subversion' to get us up to the Dec '08 version (1.5.5) which is the latest stable.

I also removed all of the old ASS medm directories without backing them up. There's a new RCG script version which is
fixed so that it no longer dumps these old medm directories in there; there's no need since there's already an
medm archive area.

I also removed the medm/old/ directory, did an svn remove, and then copied it back. This is the only way I know of
removing something from the repository without removing it from the working directory.
  1319   Wed Feb 18 15:31:38 2009 steveBureaucracySAFETYemergency back-up lights checked
All 13 exit and  emergency back-up lights and their batteries were checked.
Two of  the batteries were replaced.
  1318   Wed Feb 18 03:25:25 2009 YoichiUpdateComputersmedm directory back
I restored the medm directory from the backup on the tape.
The directory had an svn property svn:ignore set and the value of the property included *.snap and *.req.
This resulted in the exclusion of those files from the repository.
I fixed this problem by changing the property of all the directories under /cvs/cds/caltech/medm.
After fixing several other svn problems, the current medm directory contents were checked in to the repository.
  1317   Wed Feb 18 03:17:40 2009 YoichiUpdateLSCLocking
Yoichi, Kakeru,

Last night, the cm_step script failed at the hand-off of CARM error signal from TR_DC to PO_DC.
This was fixed by reducing the PO_DC gain by a factor of 2.
Currently the script fails when changing C1:LSC-DEMOD_GAIN to zero.
To be honest, I don't fully understand the purpose of this step.
  1316   Tue Feb 17 05:20:11 2009 YoichiUpdateLSCLocking
Since we excluded *.snap and *.req files from the svn control in the medm directory and these were not restored by the svn co, the burt part of the align/mis-align scripts were not working correctly this evening. So I recreated .req files and cooked up some mis-aligned .snap files.
After some cut-and-try work, I was able to run the dither alignment scripts fine.

Due to the above mentioned delay, the locking work started around midnight.

Tonight, the DD hand-off was not robust. I spent sometime to optimize this.
After the optimization, the locking proceeded to the DC CARM/DARM control state stably.
The CARM->MCL hand-off failed because the LSC-MC offset button was off.
I added a line to turn on the button in the ontoMCL script.
Today, the offloadMCF script worked fine.

Next, the cm_step script stumbled on the "ENGAGERIZING" of the AO path.
I got a hunch that the AO path might not be connected to the MC board.
Indeed, OMC_OSC_FM was connected to the IN2 of the MC board. Looks like it was used for the optimization of the modulation frequencies.
Probably I had the hunch because I did it Smile

I was able to increase the arm power up to 3.9.
The script failed when it tried to switch the CARM signal from TR_DC to SPOB_DC.
I haven't tackled on this issue yet.
  1315   Mon Feb 16 23:09:52 2009 ranaUpdateElectronicsMC Servo Board offset gone bad!

The attached plot shows that someone broke the MC_SUM_MON channel around 10:30 AM this past Wednesday the 11th. This is the EPICS monitor of the MC error point.

Come forward now with your confession and I promise that I won't let Steve hurt you.

Attachment 1: mcoff.png
mcoff.png
  1314   Mon Feb 16 22:58:51 2009 rana, yoichiConfigurationSUSHysteresis in SUS from Misalignments
WE wondered if there was some hysteresis in the SUS alignments. When we leave the optics misaligned for a
long time it seems to take awhile for the optic to settle down. Possibly, this is the slow deformation of
the wires or the clamps.

The attached PNG shows the plot of the bias sliders for a few days. You can see that we misalign some of the
optics much more than the others. This must be stopped.

Kakeru is going to use his nearly complete optical lever calibrations to quatify this by stepping the optics
around and measuring the effect in the optical lever. Of course, the misalignment steps will be too large to
catch on the OL, but he can calibrate the align-sliders into radians to handle this.
Attachment 1: a.png
a.png
  1313   Mon Feb 16 21:49:06 2009 Kakeru, RanaUpdateIOOWFS

We centerd the input of WFS QPD.

  1312   Mon Feb 16 20:47:48 2009 ranaConfigurationIOOMode Cleaner WFS Loop Gain change
I found the MCWFS gain slider down at 0.012. In this state the UGFs are probably around 10-30 mHz
and so there is no reduction of seismic noise. It is mainly a DC alignment tool in this state.

We often have reduced the loop gain thusly, to prevent the dreaded "MCWFS eating CM loop gain" disease.
That disease is where there are CM loop instabilities at ~5-30 Hz because of loop cross-couplings
who's exact nature has never been understood (TBI).

Today, I implemented a 4th order, 7 Hz low pass (RLP7) into the loops and turned up the gain by a factor
of 30 to 0.3. In this state, the damping time constants seem to be ~0.5-2 seconds as shown in the first
PDF. I didn't have enough patience to do the interminable swept sine measurements down to 0.1 Hz.

The second PDF shows the Bode plot of the RLP7 filter compared to the pre-existing but unused ELP10.

The third PDF shows my estimate of the OLG TF. This is made by just putting a "Pendulum" filter into the
MCWFS bank and then plotting all the filters together using FOTON. The BLUE curve shows the old TF but
with the new high gain and the RED curve shows the new TF with the new gain.

With this new filter, I bet that we can get away with the higher WFS gain, but if there's any problem during the
handoff, the gain should be reverted to the low value.


In the 4th PDF file, I plot the spectra of 4 of MC2's control signals so that you can see what is bigger than what.
ASCPIT is the one that has the feedback from the WFS's in it. These are all just in units of counts and so to compare
them in some sort of displacement units you have to take into account the pitch moment of inertia, the mirror mass,
and the mis-centering of the beam from the center of rotation of MC2...
Attachment 1: pmc-pzt-cal.pdf
pmc-pzt-cal.pdf
Attachment 2: a.pdf
a.pdf
Attachment 3: olg.pdf
olg.pdf
Attachment 4: mc2.pdf
mc2.pdf
  1311   Mon Feb 16 16:26:29 2009 robUpdateComputersmedm directory wiped on nodus

Quote:

Quote:
I accidentally did an 'rm -rf' on the medm directory in nodus, instead of on my laptop as was intended.

I then did an svn checkout. So everything should be current as of the last update, but I am sure that
we have not done a checkin on all of the latest screen enhancements. So...we may have to revert to the
Sunday morning tar to get the latest changes back.


Indeed, some changes to the medm directory I made were lost.
It was my fault not to check-in those changes.
I asked Alan to restore the directory from the daily rsync backup.
However, the backup job executed this morning have already overwritten the previous (good) backup with the current (bad) medm directory, which Rana restored from the svn. Alan will ask Stuart and Phil if there is still older backup remaining somewhere.

Anyway, I realized that we should stop the backup cron job whenever you think you made a mistake on /cvs/cds/ directory to prevent unwanted overwriting.
The procedure is:
(1) Login to fb40m
(2) Type 'crontab -e'. Emacs will open up in the terminal.
(3) Comment out the backup job (insert # at the beginning of the line containing /cvs/cds/caltech/scripts/backup/rsync.backup ).
(4) Save the file (Ctrl-x Ctrl-s) and exit (Ctrl-x Ctrl-c).

I will post this information on the wiki.


We should change the rsync script so that it does not delete stuff. Maybe it can keep deleted stuff for 6 months or something.
  1310   Mon Feb 16 15:54:07 2009 YoichiUpdateComputersmedm directory wiped on nodus

Quote:
I accidentally did an 'rm -rf' on the medm directory in nodus, instead of on my laptop as was intended.

I then did an svn checkout. So everything should be current as of the last update, but I am sure that
we have not done a checkin on all of the latest screen enhancements. So...we may have to revert to the
Sunday morning tar to get the latest changes back.


Indeed, some changes to the medm directory I made were lost.
It was my fault not to check-in those changes.
I asked Alan to restore the directory from the daily rsync backup.
However, the backup job executed this morning have already overwritten the previous (good) backup with the current (bad) medm directory, which Rana restored from the svn. Alan will ask Stuart and Phil if there is still older backup remaining somewhere.

Anyway, I realized that we should stop the backup cron job whenever you think you made a mistake on /cvs/cds/ directory to prevent unwanted overwriting.
The procedure is:
(1) Login to fb40m
(2) Type 'crontab -e'. Emacs will open up in the terminal.
(3) Comment out the backup job (insert # at the beginning of the line containing /cvs/cds/caltech/scripts/backup/rsync.backup ).
(4) Save the file (Ctrl-x Ctrl-s) and exit (Ctrl-x Ctrl-c).

I will post this information on the wiki.
  1309   Mon Feb 16 14:12:21 2009 YoichiUpdateLSCFE system rebooted

Quote:

I can't restart the MC autolocker on c1susvme2 because it doesn't let me ssh in. I tried to reboot it a few times but it didn't work. Once you restart it, it becomes inaccessible and doesn't even respond to pinging. Although the controls for the MC mirrors are on.

The mode cleaner stays unlocked.


MC autolocker runs on op340m, not on c1susvme2.
I restarted it and now MC locks fine.
Before that, I had to reboot c1iool0 and restore the alignment of the MC mirrors (for some reason, burt did not restore the alignment properly, so I used conlog).
  1308   Mon Feb 16 10:18:13 2009 AlbertoUpdateLSCFE system rebooted

Quote:

Quote:

I didn't get a chance to do much testing since the sus controller (susvme1) went nuts. In retrospect, this could be due to something in the script, so maybe we should try a burt restore to Friday afternoon next time someone wants to look at it.


I tried the burtrestore today, it didn't work. Also tried some switching of timing cables, and multiple reboots, to no avail. This will require some more debugging. We might try diagnosing the clock driver and fanout modules, the penteks, and we can also try rebooting the whole FE system.


I rebooted the whole FE system and now c1susvme1 and c1susvme2 are back on.

I can't restart the MC autolocker on c1susvme2 because it doesn't let me ssh in. I tried to reboot it a few times but it didn't work. Once you restart it, it becomes inaccessible and doesn't even respond to pinging. Although the controls for the MC mirrors are on.

The mode cleaner stays unlocked.
  1307   Mon Feb 16 00:43:46 2009 ranaUpdateComputersmedm directory wiped on nodus
I accidentally did an 'rm -rf' on the medm directory in nodus, instead of on my laptop as was intended.

I then did an svn checkout. So everything should be current as of the last update, but I am sure that
we have not done a checkin on all of the latest screen enhancements. So...we may have to revert to the
Sunday morning tar to get the latest changes back.
  1306   Sun Feb 15 15:53:21 2009 RobUpdateLSCLocking status

Quote:

I didn't get a chance to do much testing since the sus controller (susvme1) went nuts. In retrospect, this could be due to something in the script, so maybe we should try a burt restore to Friday afternoon next time someone wants to look at it.


I tried the burt restore today, it didn't work. Also tried some switching of timing cables, and multiple reboots, to no avail. This will require some more debugging. We might try diagnosing the clock driver and fanout modules, the penteks, and we can also try rebooting the whole FE system.
  1305   Sun Feb 15 09:35:00 2009 YoichiUpdateLSCLocking status

Quote:

I found a '$<' in the offloadMCF script. I don't know precisely what that construct means, but I think it caused the script to wait for input when it shouldn't.


'$<' acts like 'read' in csh. I might have put it in the offloadMCF script to debug the behavior of the script.
Sorry I probably forgot to remove it from the script when I left.
  1304   Sat Feb 14 16:53:26 2009 robUpdateLSCLocking status

Quote:
Yoichi, Jenne, Alberto, Rob

Last night, the locking proceeded until the CARM -> MC_L hand-off.
However, the MC_F gets saturated (as expected) and the IFO loses lock soon after the hand-off.
So we need to offload MC_F.
We ran the offloadMCF script, but it did not work, i.e. just waiting for CARM mode.
Looks like an EPICS flag is not set right.


I found a '$<' in the offloadMCF script. I don't know precisely what that construct means, but I think it caused the script to wait for input when it shouldn't. It probably got in there accidentally. We need to be careful when we're opening scripts just to look at how they work that we don't accidentally change them. I like to use the command 'less' for this purpose.

With this gone, the script worked properly, although the lock didn't last long. I don't know if the next stage in the process is failing or if it's just a bit too noisy in the afternoon. I didn't get a chance to do much testing since the sus controller (susvme1) went nuts. In retrospect, this could be due to something in the script, so maybe we should try a burt restore to Friday afternoon next time someone wants to look at it.
  1303   Sat Feb 14 16:15:19 2009 robConfigurationComputersc1susvme1

c1susvme1 is behaving weirdly.  I've restarted it several times but its computation time is hanging out around 260 usec, making it useless for suspension control and locking.  I also found a PS/2 keyboard plugged in, which doesn't work, so I unplugged it.  It needs to be plugged into a PS/2 keyboard/mouse Y-splitter cable. 

  1302   Fri Feb 13 16:30:49 2009 steveConfigurationGeneralstatus quo is disturbed

I have been getting ready for the annual safety inspection in the past 2-3 days.

Meaning cleaning up and disturbing the status quo on the floor  mostly under the optical tables and their surroundings.
For example: pd power supplies, He/Ne laser ps. and their positions.
BNC cables and ac power line positions can be different.
The new rule: no electronic equipment on the floor.
 
All electronic equipment were moved-placed into a plastic dish or tray.
  1301   Fri Feb 13 13:35:38 2009 YoichiUpdateLSCLocking status
Yoichi, Jenne, Alberto, Rob

Last night, the locking proceeded until the CARM -> MC_L hand-off.
However, the MC_F gets saturated (as expected) and the IFO loses lock soon after the hand-off.
So we need to offload MC_F.
We ran the offloadMCF script, but it did not work, i.e. just waiting for CARM mode.
Looks like an EPICS flag is not set right.
  1300   Fri Feb 13 08:38:03 2009 steveUpdateIOOMC2 damping restored
  1299   Thu Feb 12 18:35:10 2009 KakeruConfigurationPSLPA current limitter


I added a PA current limiter.
It is only a voltage devider (composed with 3.09k and 1.02k resiste) between DAC and PA current adjustment input.
The output range of DAC is +/- 10[V] and  the conversion factor of PA current adjustment is 0.84[A/V] (measured value), so the PA current adjustment is limited +/- 2.1[A] ( 10[V]*1.02k/(1.02k+3.09k)*0.84[A/V] ).


Actually, the manual of the PA tells that the conversion factor is 0.25[A/V].
There is 3 possibility.
1) There are some mistakes in channels of digital system.
2) The PA manual is wrong.
  2-1) The conversion factor of current adjustment is wrong.
  2-2) The conversion factor of current monitor is wrong.
I measured the signal of current adjustment and current monitor directly, and confirm that they are consistent to the value monitord from MEDM.
Hence the PA manual must be wrong, but I don't know which factor is wrong (or both?).
If the suspect 2-2) is guilty, it means we adjust PA current with very small range.
This is a completly safety way, but a wast of resource.


Now, the slider to control current adjustment indicate the output of DAC.
I will improve this to indicate  current adjustment input, but it takes some time for me to learn about EPICS.

  1298   Thu Feb 12 17:43:33 2009 YoichiUpdateLSCSRC strangeness solved
I found the problem with the DRMI lock I had last night was caused by the zero gain in the PD11_I filter.
I don't know how it happened but putting it back to 1.000 made the DRMI lock far more stable and AS166Q got more than 3000.

I also re-centered POY PD to remove the offset in the y-arm loop. The large power drops while y-arm is locked by itself were eliminated.
  1297   Thu Feb 12 14:39:07 2009 ranaSummaryGeneralSilicon Beam Dump test
Yesterday evening, Ken Mailand and I tested the reflectivity of a piece of polished Silicon. Since Silicon has such a high thermalconductivity (compared to stainless and fused silica) and can take much more heat than black glass and should have a very good BRDF and should absorb most of the 1064 nm light if we hit it at Brewster's angle, we want to try it out in the first version high power, low scatterbeam dump. This dump will be a 'V' style dump like what Steve has tested nearly a year ago, but the incoming beam will first hit this piece of Silicon.

The pictures of the setup and the Silicon with the beam hitting it are here.

Brewster's angle for p-pol at 1064 nm is 74.2 deg (n = 3.53 @ 1064 nm). We set up a cube polarizer on the output of the ~1064 nm CrystaLaser. 144 mW got to the Si; the reflected beam was ~1.9-2.0 mW after tuning the angle for minimum power. Via eyeball and protractor it seems that we're at ~74 deg. So the reflectivity is < 1.5-2%. This is good enough; the reflected power will be < 1 W in all cases for eLIGO and that can be absorbed by the rest of the stainless V dump. The 35 W of heat in the silicon will be mostly gotten rid of through conduction into the attached heat sink fins.

This kind of dump would go into places like the PMC-REFL, MC-REFL, & IFO-REFL, where we occasionally need to take high power, but also are sensitive to backscatter.
  1296   Thu Feb 12 11:21:54 2009 YoichiUpdateLSCLocking effort resumed
Last night, I restarted the locking work.
Quite some time was wasted by the disconnected REFL199 by Alberto for the cavity length measurement.
From now on, please put the interferometer back to the original state every day.
If possible, please refrain from changing the IFO settings (cabling, optics, etc).
It is also very important to always restore the full IFO alignment after you are done with your work.

While I was working on the optimization of the DD hand-off, the DRMI alignment got into a strange state.
Even when I did the whole dither alignment procedure from the beginning (from x-arm), the AS166Q did not go above 1000.
PRMI looks ok (SPOB goes above 1100). I could lock the DRMI but the lock position hops to other modes easily.
Manual tweaks of SRM did not help.
After running the whole alignment procedure several times in vain, I was too tired and went home.
I noticed that the single arm lock shows power drops again. There are some offsets in the arm lock loops.
This may have prevented the Michelson alignment from being optimal. I will check this today.
  1295   Wed Feb 11 23:51:53 2009 KakeruUpdatePSLPA current and laser output
I attached a plot of ISS monitor PD and MOPA output to PA current.
The both end of PA current (26.0353[A] and 28.4144[A]) correspond to the slider value of -2.0 and 1.0 .
It looks that we must use MOPA with PA current below 27.5[A].
Attachment 1: PA_current_output.png
PA_current_output.png
  1294   Wed Feb 11 15:01:47 2009 josephbConfigurationComputersAllegra

So after having broke Allegra by updating the kernel, I was able to get it running again by copying the xorg.conf.backup file over xorg.conf in /etc/X11.  So at this point in time, Allegra is running with generic video drivers, as opposed to the ATI specific and proprietary drivers.

  1293   Wed Feb 11 11:39:17 2009 steveConfigurationGeneralvac envelope ground
The vacuum envelope was grounded from the IOO chamber to master ground north (under electric breaker panel L)
with 4GA  25ft red battery cable.

 

  1292   Wed Feb 11 10:52:22 2009 YoichiConfigurationDAQC1:PEM-OSA_APTEMP and C1:PEM-OSA_SPTEMP disconnected

During the cleanup of the lab. Steve found a box with two BNCs going to the ICS DAQ interface and an unconnected D-SUB on the floor under the AP table.  It seemed like a temperature sensor.

The BNCs were connected to C1:PEM-OSA_APTEMP and C1:PEM-OSA_SPTEMP.

Steve removed the box from the floor. These channels can be now used as spare DAQ channels. I labeled those cables.

  1291   Wed Feb 11 07:28:25 2009 YoichiUpdatePSLPA current and laser output
I think we should also plot the laser power at the MOPA output. The horizontal axis should be the absolute current value read from the PA current monitor channel, not the slider value.

This result is consistent with my hypothesis that the thermal effect is canceling the power change at low frequencies (see elog:1276).
But if it is really caused by thermal effect or not is still unknown.

I'd like to see a larger scan into the lower current region.


Quote:
I changed the PA current and measured laser output power (monitor PD signal).
The gain of ISS is 13dB
Attached figure is the relation of PA current and the average and standard diviation of laser output.
The average of output power decreas as current increase. It looks something is wrong with PA.
When current is -0.125, 0, 0.5, ISS become ocsilating. This looks to be changed from previous measurement.

I wrote matlab code for this measurement. The code is
/cvs/cds/caltech/users/kakeru/scripts/CS_evaluate.m
This function uses
/cvs/cds/caltech/users/kakeru/scripts/moveCS.m
  1290   Wed Feb 11 00:50:24 2009 carynUpdateGeneralants?

So, near 2 of the trashcans in the control room and underneath a desk there are hundrends of ants. Is this normal?

  1289   Tue Feb 10 23:36:25 2009 KakeruUpdatePSLPA current and laser output
I changed the PA current and measured laser output power (monitor PD signal).
The gain of ISS is 13dB
Attached figure is the relation of PA current and the average and standard diviation of laser output.
The average of output power decreas as current increase. It looks something is wrong with PA.
When current is -0.125, 0, 0.5, ISS become ocsilating. This looks to be changed from previous measurement.

I wrote matlab code for this measurement. The code is
/cvs/cds/caltech/users/kakeru/scripts/CS_evaluate.m
This function uses
/cvs/cds/caltech/users/kakeru/scripts/moveCS.m
Attachment 1: PA_current_output.png
PA_current_output.png
  1288   Tue Feb 10 10:48:48 2009 steveBureaucracySAFETYsafety glasses scanned
All 40m safety glasses are absorbent.
 
They were scanned by 180 mW  2mm spot size  of 1064 nm beam and  their  transmissions were measured
They showed no degradation.
 
UVEX 's  LOTG-YAG/CO2 glasses (fits over personal glasses) 11 pieces,
Glendale-XC by Bacou-Dalloz,  #1166218VLT68% , aerodynamic style, 7 pieces, (4 missing )
KG5- glasses , heavier- made out of glass, 3 pieces,
Thorlab's LG10, 1 piece
Old glasses by "Laser Glass" Nd-YAG, 2 pieces
Totaling 24
 
Atm.2  showing our muilty wavelength glasses of 1064 and 530 nm
Their transmittance for both wavelength were zero.
 
Note: if you have prescripton safety glasses I would like to scan it for you !
 
 
 

 

 

Attachment 1: sgscan1.png
sgscan1.png
Attachment 2: sgscan2.png
sgscan2.png
  1287   Mon Feb 9 19:50:48 2009 YoichiConfigurationPSLISS disconnected
We are doing measurements on ISS.
The ISS feedback connector is disconnected and the beam to the MC is blocked.
  1286   Mon Feb 9 17:09:51 2009 YoichiUpdateComputersA bunch of updates for the network GPIB stuff.
During the work on ISS, we noticed that netgpibdata.py is very unreliable for SR785.
The problem was caused by flakiness of the "DUMP" command of SR785, which dumps the data from the analyzer to the client.
So I decided to use other GPIB commands to download data from SR785. The new method is a bit slower but much more reliable.

I also rewrote netgpibdata.py and related modules using a new class "netGPIB".
This class is provided by netgpib.py module in the netgpibdata directory. If you use this class for your python program, all technical details and dirty tricks are hidden in the class methods. So you can concentrate on your job.
Since python can also be used interactively, you can use this class for a quick communication with an GPIB instrument.

Here is an example.
>ipython #start interactive python
>>import netgpib #Import the module
>>g=netgpib.netGPIB('teofila',10) #Create a netGPIB object. 'teofila' is the hostname of
#the GPIB-Ethernet converter. 10 is the GPIB address.
>>g.command('ACTD0') #Send a GPIB command "ACTD0". This is an SR785 command meaning "Change active display to 0".
>>ans=g.query('DFMT?') #If you expect a response from the instrument, use query command.
#For SR785, "DFMT?" will return the current display format (0 for single, 1 for dual).
>>g.close() #Close the connection when you are done.

Sometimes, SR785 gets stuck to a weird state and netgpibdata.py may not work properly. I wrote resetSR785.py command to reset it remotely.
Wait for 30sec after you issue this command before doing anything.

I wrote two utility commands to perform measurements with SR785 automatically.
TFSR785.py commands SR785 to perform a transfer function measurement.
SPSR785.py will execute spectrum measurements.
You can control various parameters (bandwidth, resolution, window, etc) with command-line options.
Run those commands with '-h' for help.
It is recommended to use those commands even when you are in front of the analyzer, because they save various measurement parameters (input coupling, units, average number, etc) into a parameter file along with the measured data. Those parameters are useful but recording them for each measurement by hand is a pain.
  1285   Mon Feb 9 16:05:01 2009 YoichiUpdateLSCDRMI OK

After the ISS work, I aligned the IFO and confirmed that DRMI locks with good SPOB and AS166 values.

  1284   Mon Feb 9 16:02:42 2009 YoichiUpdatePSLPSL relative intensity noise
I attached the relative intensity noise of the PSL.
There is no bump around the lower UGF (~1Hz), but at the higher UGF (~30kHz) there is a clear bump.
When the ISS gain slider was moved up to 21dB, the peak got milder, because there is larger phase margin at higher frequencies with the current filter design.
We may want to optimize the filter later.
Attachment 1: RIN-13dB.png
RIN-13dB.png
Attachment 2: RIN-21dB.png
RIN-21dB.png
  1283   Fri Feb 6 23:23:48 2009 Kakeru, YoichiUpdatePSLISS is fixed

Yoichi and me found that the transfar function of the current shunt changed with the current of PA.
We changed PA current and fixed the unstability of ISS.
Now, laser power is stabilized finely, with band of about 1 Hz.
Yoich will post the stabilized noise spectrum.

There looks to be some non-linear relation between PA current and  the TF of current shunt.
It had changed from the TF which we measured yesterday, so it might change again.

I try to write scripts to sweep PA current and measure the laser power and its rms automatically.
It will be apply for auto-adjustment of PA current.


Attached files are the transfar function of the current shunt with changing PA.
They have difference in lower frequency.

Attachment 1: Current_ShuntTF_gain.png
Current_ShuntTF_gain.png
Attachment 2: Current_ShuntTF_phase.png
Current_ShuntTF_phase.png
  1282   Fri Feb 6 16:23:54 2009 steveUpdateMOPAMOPAs of 7 years

MOPAs and their settings, powers of 7 years in the 40m

Attachment 1: 7ymopas.jpg
7ymopas.jpg
  1281   Fri Feb 6 16:20:52 2009 YoichiUpdatePSLMOPA current slider fixed

I fixed the broken slider to change the current of the PA.

The problem was that the EPICS database assigned a wrong channel of the DAC to the slider.

I found that the PA current adjustment signal lines are connected to the CH3 &CH4 of VMIC4116 #1. However in the database file (/cvs/cds/caltech/target/c1psl/psl.db), the slider channel (C1:PSL-126MOPA_DCAMP) was assigned to CH2. I fixed the database file and rebooted c1psl. Then the PA current started to follow the slider value.

I moved the slider back and forth by +/-0.3V while the ISS loop was on. I observed that the amount of the low frequency fluctuation of the MOPA power changed with the slider position. At some current levels, the ISS instability problem went away.

Kakeru is now taking open-loop TFs and current shunt responses at different slider settings.

  1280   Fri Feb 6 14:49:31 2009 steveSummarySAFETYlaser inventory
40M Laser Inventory at Feb 05, 2009
 

1, Lightwave PA#102 @ 77,910 hrs 1064nm of 2.8W @ 27.65A
                   NPRO#206 @ 2.4A                    at PSL enclosure............"Big Boy" is waiting for to be retired but not now.

2, Lightwave  NPRO 1064nm of 700mW  #415   at AP table.......cavity length measurements of Alberto

3, CrystaLaser  IRCL-100-1064S, 1064nmS of 100mW  ,sn#IR81132 at east arm cabinet

4, CrystaLaser 1064nm of 180mW # -1274 flq at scattering setup.........flashlight quality

5, RF-PD tester 1064nm of 1.2mW @20mA at SP table

6, Lumix 800-1100nm of 500mW at east arm cabinet

7, JDS-Uniphase 633nmP of 4mW oplev sus laser at 5 places,
    plus four spares in east arm cabinet
 
 
The same information is posted at the 40M WIKI also
 
 
 
ELOG V3.1.3-