40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 13 of 341  Not logged in ELOG logo
ID Date Author Typedown Category Subject
  1276   Thu Feb 5 21:42:28 2009 YoichiUpdatePSLMy thoughts on ISS

Today, I worked with Kakeru on ISS.

The problem is sort of elusive. Some time, the laser power looks fine, but after a while you may see many sharp drops in the power. Some times, the power drops happen so often that they look almost like an oscillation.

We made several measurements today and Kakeru is now putting the data together. Meanwhile, I will put my speculations on the ISS problem here.

The other day, Kakeru took the transfer function of the ISS feedback filter (he is supposed to post it soon). The filter shape itself has a large phase margin ( more than 50deg ?) at the lower UGF (~3Hz) if we assume the response of the current shunt to be flat. However, when we took the whole open loop transfer function of the ISS loop, the phase margin was only 20deg. This leads to the amplification of the intensity noise around the UGF. The attached plot is the spectrum of the ISS monitor PD. You can see a broad peak around 2.7Hz. In time series, this amplified intensity noise looks like semi-oscillation around this frequency.

Since it is very unlikely that the PD has a large phase advance at low frequencies, the additional phase advance has to be in the current shunt. We measured the response of the current shunt (see Kakeru's coming post). It had a slight high-pass shape below 100Hz (a few dB/dec). This high-pass response produces additional phase advance in the loop.

There seems to be no element to produce such a high-pass response in the current shunt circuit ( http://www.ligo.caltech.edu/docs/D/D040542-A1.pdf )

This Jamie's document shows a similar high-pass response of the current ( http://www.ligo.caltech.edu/docs/G/G030476-00.pdf  page 7 )

Now the question is what causes this high-pass response. Here is my very fishy hypothesis :-)

The PA output depends not only on the pump diode current but also on the mode matching with the NPRO beam, which can be changed by the thermal lensing. If the thermal lensing is in such a condition that an increase in the temperature would reduce the mode matching, then the temperature increase associated with a pump current increase could cancel the power increase. This thermal effect would be bigger at lower frequencies. Therefore, the intensity modulation efficiency decreases at lower frequencies (high-pass behavior). If this model is true, this could explain the elusiveness of the problem, as the cancellation amount depends on the operation point of the PA. 

To test this hypothesis, we can change the pump current level to see if the current shunt response changes. However, the PA current slider on the MEDM screen does not work (Rob told me it's been like this for a while). Also the front panel of the MOPA power supply does not work (Steve told me it's been like this for a while). We tried to connect to the MOPA power supply from a PC through RS-232C port, which did not work neither. We will try to fix the MEDM slider tomorrow.

Attachment 1: INMONPD_Spectrum_1-10Hz.pdf
INMONPD_Spectrum_1-10Hz.pdf
  1277   Fri Feb 6 09:52:35 2009 KakeruUpdatePSLCurrent shunt transfar function

I attach the transfar function of the current shunt.
There is a little gap at 10 Hz for phase, but it is a ploblem of measurement and not real one.
 

Attachment 1: TF_CS_gain.png
TF_CS_gain.png
Attachment 2: TF_CS_phase.png
TF_CS_phase.png
  1278   Fri Feb 6 09:56:11 2009 KakeruUpdatePSLISS servo transfar function

I attache the transfar function of ISS servo.

The 4th stage and variable gain amplifier has alomost same transfar function, so their lines pile up.

Attachment 1: TF_ISSservo_gain.png
TF_ISSservo_gain.png
Attachment 2: TF_ISSservo_phase.png
TF_ISSservo_phase.png
  1279   Fri Feb 6 10:46:40 2009 KakeruUpdatePSLISS servo and noise
I measured the output noise of eache stage of ISS servo, and calcurated the noise ratio between input and 
output of each stage.
Generaly, each noise ratio corresponds to their transfar function. This means servo filter works well, not 
adding extra noise.

I attache example of them.
For 2nd stage, the noise ratio is smaller than transfar function with a few factor. This is because the 
input noise is coverd by analyser's noise and ratio between output and input looks small.
This means the input noise of 2nd stage was enough small and all stage before 2nd stage work well
Attachment 1: ISS_servo_TF_noise.png
ISS_servo_TF_noise.png
  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.

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

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

  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
  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
  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.
  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.
  1300   Fri Feb 13 08:38:03 2009 steveUpdateIOOMC2 damping restored
  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.
  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.
  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.
  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.
  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.
  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.
  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).
  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.
  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.
  1313   Mon Feb 16 21:49:06 2009 Kakeru, RanaUpdateIOOWFS

We centerd the input of WFS QPD.

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

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

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

 

  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.

 

 

  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
  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.
  1330   Fri Feb 20 19:31:16 2009 YoichiUpdateLSCMICH low gain problem
Last night, we found that MICH UGF was too low. Even after re-aligning the PDs, it was still too low.
Today, I compared the UGFs of MICH and PRC when in the DRMI configuration locked with the single demod. signals.
In this configuration, MICH signal comes from REFL33Q and the PRC signal comes from REFL33I (the same PD).
The PRC UGF was about 100Hz whereas MICH was only ~10Hz.
Since they uses the same PD, the low gain is not caused by the PD.
I checked conlog history and confirmed there is no change in the MICH->BS path in the last few days.
I also checked the svn history of chans directory for changes in filters. Nothing problematic found.

Then I noticed that the susvme computers were overloaded.
This time, I rebooted all the FE computers just in case.

Then the MICH gain was somewhat recovered (by a factor of 3 or so). Don't know why.

I adjusted the DD_handoff script to set the MICH gain to 0.7 before the bounce-roll filter is engaged.
  1334   Tue Feb 24 02:23:40 2009 YoichiUpdateLockingLocking - MC board bad
Rob, Yoichi, Alberto, Kiwamu, Kakeru

We found that the OMC alignment feedback was on for the POS X loop even though the OMC was not locked.
This caused the PZT mirror to be tilted in yaw a lot. This was probably the reason for the mysterious shift in the AS beam last week, because the AS RF beam is picked up after this PZT mirror.
Rob aligned the OMC and we re-centered the AS PDs and the CCD.
This changed the DARM RF gain, so we changed it from 3 to 1. This gain used to be -1. It is still not understood why the polarity was changed.
The MC length was changed ? We should check the sideband transmission.

After this, we reached to the arm power 4. But the IFO loses lock immediately after the moving zero is turned off.
At this stage, the CARM loop bandwidth is supposed to be high enough that the moving zero is no longer necessary.
However, when we measured the MCL loop gain with several different AO path gains, the loop shape did not change at all.
This led us to suspect the AO path may not be connected. The cabling from the common mode board to the MC board seemed ok.
We tested the signal flow in the MC board using a signal generator and an oscilloscope.
Then we found that a signal injected to the IN2 (AO path) does not reach to the TP1A (right after the boost stages), though the signal is visible in the OUT2 (monitor BNC right after the initial amplifier (B-amp) for the AO path). The signal from IN1 (MC REFL) can be observed at TP1A. This means something is broken between the B-amp and the sum-amp in the AO path.
We will check the MC board tomorrow.
  1335   Tue Feb 24 18:42:15 2009 peteUpdateLockingmc board repair
Peter, Yoichi
Last night:


Quote:
However, when we measured the MCL loop gain with several different AO path gains, the loop shape did not change at all. This led us to suspect the AO path may not be connected. The cabling from the common mode board to the MC board seemed ok. We tested the signal flow in the MC board using a signal generator and an oscilloscope. Then we found that a signal injected to the IN2 (AO path) does not reach to the TP1A (right after the boost stages), though the signal is visible in the OUT2 (monitor BNC right after the initial amplifier (B-amp) for the AO path). The signal from IN1 (MC REFL) can be observed at TP1A. This means something is broken between the B-amp and the sum-amp in the AO path. We will check the MC board tomorrow.


Today we examined the MC board. With the extension board in place everything seemed fine. Without the extension board we could replicate the problem. Jiggling the IN2 jack caused the injected signal observed at TP1A to come and go. These jacks are unfortunately mounted directly on the board. We traced the problem to a resistor in this path (R30) which looked fishy. We soldered on a new 2K resistor with OWC and it fixed the problem.
  1336   Wed Feb 25 03:10:24 2009 YoichiUpdateLockingLocking status
Rob, Yoichi, Kakeru, Kiwamu

Tonight, CARM -> MCL hand off was not stable. The MCF signal monotonically went up to +2V after CARM and MCL gain was turned down to zero.
This was repeatable and it only goes up (not down).
After a while, we found that putting sleep (~5sec) between the zeroing of CARM gain and MCL gain prevents this problem.

Handing off of CARM error signal from TR to PODC was also not robust.
It seems that the suitable gain changes every time.

tdsavg started to exit with errors. We rebooted fb40m.
When tdsavg returns an error, the cm_step script tries to write NaN into SPOB DC offset.
To prevent this, I put the tdsavg in a while loop which runs until tdsavg returns something other than NaN.

I was able to hand off to PODC several times, but could not proceed further because the IFO lost lock soon.
  1337   Wed Feb 25 11:48:02 2009 JenneUpdatePEMWiener filtering update - work on filtering some S5 DARM_CTRL data

Quick update on my wiener filtering status:

Joe has been helping me get on the GRID, so I now have  a grid certificate, and accounts on most/all of the clusters.

Joe also helped me get menkar to get S5 data so that I can do wiener filtering to the back-data. 

 

I've been running the wiener filtering algorithm, and right now, it doesn't do anything to improve the DARM_CTRL data.  I am confident that this is because something is funky in the wiener filtering algorithm somewhere.  The indicator of this is that the wiener filtering calculation takes the same amount of time (~95 seconds) to calculate a filter for 64 seconds of data as for 1 hour of data (both for N = 2000 taps). 

 

For reference, attached are my plots for the wiener filtering result for (1) 64 seconds of S5 data, and for (2) 3600 seconds of S5 data.

These plots were made using H1:DARM_CTRL as the signal to minimize, with 4 seismometers as the witness channels (EX_SEISX, EY_SEISY, LVEA_SEISX, LVEA_SEISY)

 

I'm working on figuring out what's going on with the filtering algorithm, and why it does work for C1:MC_L minimization, but does not work for H1:DARM_CTRL minimization.

 

 

 

Attachment 1: h1_DARM_64s_4seis_25Feb09.png
h1_DARM_64s_4seis_25Feb09.png
Attachment 2: h1_DARM_3600s_4seis_25Feb09.png
h1_DARM_3600s_4seis_25Feb09.png
  1339   Thu Feb 26 01:24:44 2009 YoichiUpdateComputersMartian wireless is back
Today, a new wireless router arrived.
I configured and installed it. Now the martian wireless network is back.
I updated the wiki page about the wireless network.
http://lhocds.ligo-wa.caltech.edu:8000/40m/Network
  1341   Thu Feb 26 19:59:23 2009 YoichiUpdateLockingDaytime locking
Osamu, Yoichi

We tried locking today from about 2PM.
It took about 1000sec on average to acquire the initial lock.
After the initial lock is achieved, the hand-off/ramp-up steps were reasonably robust, although the AS beam sometimes fluctuates a lot (not good for mental health).

Like last night, the IFO loses lock at around arm-power=8.
We measured the CARM AO path loop gain at arm-power=4. We used the SR785 connected to the A-excitation channel of the common mode board through my TFSR785.py script.

The first attachment is the transfer function measured right after the arm power was ramped up to 4.
The overall bandwidth of the CM servo is only 400Hz. Note that since this is the loop gain of only the AO path, the low frequency gain is eaten by the MCL path.
The second attachment is the same transfer function measured after the AO path gain was increased by 6dB.
It is evident that the AO path is working.
We increased both the AO path and MCL gain by 18dB. The third attachment is the AO path TF in this state.
We then increased the arm power but lost lock at arm-power=6. We should have checked the DARM loop too.
BTW, these plots are automatically generated when you use TFSR785.py for transfer function measurements.


I added -notickle option to c1_watch_dr_bang, since tickling seems to be not necessary during the daytime (actually the initial lock was easier with no tickling).

As the construction work in the next building is now calmed down, I think it is ok to do locking during the day time, though I still plan to come at night.
The improvement of my brain efficiency during the day time may compensate for the longer wait time for initial lock.
Attachment 1: CM1.png
CM1.png
Attachment 2: CM2.png
CM2.png
Attachment 3: CM3.png
CM3.png
  1343   Fri Feb 27 13:49:19 2009 robUpdateLockingthurs night

Could not get past arm power of ~11 or so.  I was suspicious of the transmon high-gain/low-gain PD handover, so I ran the matchTransMon scripts, but that did not help.  I also removed the line in the cm_step script that increased the CM gain by 18dB at an arm power of 4.  The gain of the CM servo will increase naturally as the power in the IFO builds up, so it may not be good to crank it right away.  I tried several other CM gains, and watched the DARM loop, but still could not get past an arm power of ~10-11.  I'm not sure what's wrong, but it may be that mysterious CM-servo/McWFS conspiracy, so we can try turning down the McWFS gain next time.

  1344   Mon Mar 2 03:57:44 2009 YoichiUpdateLockingSunday night locking
Tonight's locking started with a boot fest of the FE computers which were all red when I came in.
It also took me sometime to realize that C1:IOO-MC_F was returning always zero to tdsavg, causing the offloadMCF script to do nothing.
I fixed this by rebooting c1iovme and c1iool0.

Like Rob on the thursday night, I was only able to reach arm power around 10.
This time, I turned down the MC WFS gain to 0.02 (from 0.3).
I also checked gains of most of the loops (MICH, PRC, SRC, DARM, CARM-MCL, CARM-AO).
All the loops looked fine until the lock was lost suddenly. Also the spectrum of MC_F did not change as the arm power was ramped up.
Actually, I was able to reach arm power=10 only once because I spent a long time checking the loop gains and spectrum at fine steps of the arm power.
So it is quite possible that this loss of lock was just caused by a seismic kick.
  1346   Mon Mar 2 21:16:32 2009 YoichiUpdateLockingLow-gain High-gain PD switching may not be working well
Osamu, Yoichi

This afternoon, I run the locking script while doing calculations for the upgrade.
The IFO lost lock even at lower arm powers (around 6) if it was operated for a while (~ 5min).
It seemed as if there were some intermittent glitches (seismic? laser?) causing the lock losses.
We also saw once the TRX and TRY signals saturated at around arm power = 11 when there was a large fluctuation in the arm power.
Osamu suggested that it looked like the high-gain to low-gain PD switching was not working.

I won't come tonight as I may have caught a cold, but if someone comes tonight, it is worth checking the PD switching.
ELOG V3.1.3-