 Fri Feb 1 12:37:39 2008, rob, Update, DMF, seisBLRMS trends 
|
Here are DV trends of the output of seisBLRMS over the last ~36 hours (which is how long it's been running), and another of the last 2 hours (which show the construction crew taking what appears to be a lunch break). |
|
Sun Feb 3 05:02:41 2008, rana, Update, PEM, Seism 4 day
|
|
|
Wed Feb 6 09:17:31 2008, steve, Update, PEM, IST building construction continoues
|
| The bulldosers at work |
|
Fri Feb 8 17:09:52 2008, Max Jones, Update, Computers, Changes to NoiseBudget
|
Today I altered the following files
caltech/NB/matlab/utilities/get_dtt_dataset
In DARM_CTRL case I changed the second channel name to DARM_ERR. Messy but it may be effective.
caltech/NB/matlab/noise/getUGF.m
I commented out lines of code specifically pertaining to non-existent DARM_DAQ channel. Marked in
code around approximately line 60.
Please address all comments or concerns to me (williamj(at symbl)caltech.edu). Thank you. |
|
Mon Feb 11 14:24:19 2008, steve, Update, PEM, more earthquakes
|
ITMX and ITMY sus damping restored after Baja earthquake 5.1 mag at 10:29 this morning.
The ground preparation for The ITS building is almost finished.
Activity is winding down, however the Baja California_ Mexico earthquake zone
"Guadala Victoria" started acting up on Friday.
http://earthquake.usgs.gov/eqcenter/recenteqsus/Maps/special/California_Nevada_eqs.php |
|
Tue Feb 12 16:39:52 2008, rob, Update, Locking, report
|
Did some locking work on DRFPMI on sunday and (with John) on monday nights. So far progress has not been terribly encouraging.
Problems include the DD_handoffs not working and the CARM->MCL handoff not working so well. To get around the DD signals trouble, I decided for now to just ignore 67% of the DD signals. We should be able to run with PRC & MICH on single demod signals, and SRC on a DD signal. This seems to work well in a DRMI state, and it also works well in a DRMI+2ARMs state.
The CARM->MCL handoff actually works, but it doesn't take kindly to the AO path and it doesn't work very stably. I guess this was always the most fragile part of the whole locking procedure, and it's fragility is really coming to light now. Investigation continues. |
|
Wed Feb 13 11:41:00 2008, Alberto, Update, Electronics, Some characterization of the RF Monitor Box (StocMon)
|
I'm attaching a table with some measurements and the power spectrum from the pd to help evaluate the numbers.
The box output ranges from 0.5V to 2.1V. The coefficient between power and voltage is negative so higher voltage means lower power.
The red numbers are the outputs from each channel at their resonant frequencies. As one can see these are not very well centered on the dynamic range of the power detectors.
The cross coupling seems to be not a problem.
Even if the 166 filter, which handles the smallest of the frequencies and is also the most lossy (for construction reason), mounts a preamplifier, the output is still rather small. this explain also the high bias due to the noise amplification at the maximum power (13dB). A better insertion loss either remaking the filter or re-tuning that one would simplify many problems, i.e. there is not much room in the metal pomona box to fit the amplifier. I might want to consider, after everything else is ready and if I have time before leaving next week, to work on a new 166 filter. |
|
Wed Feb 13 20:37:11 2008, John, Update, LSC, Fibre locking - Fiber
|
| Sam and I observed fringes in the light reflected from the Y arm. These fringes are due to the sidebands and not the carrier. To improve matters we plan to reduce the RF AM and increase our modulation index. |
|
Thu Feb 14 17:21:53 2008, Max Jones, Update, Computers, Noise budget code changes
|
In cvs/cds/caltech/NB/matlab/utilities/LSCmodel.m at line 146
I have hardwired in changes to struct lsc. Please see code. |
 Fri Feb 15 10:28:44 2008, rana, Update, Computers, Noise budget code changes
|
| Quote: | In cvs/cds/caltech/NB/matlab/utilities/LSCmodel.m at line 146
I have hardwired in changes to struct lsc. Please see code. |
The IFOin variable (which I admit is not documented) should refer to a file called
C1IFOparams.m in the ReferenceData directory. This does not yet exist but can be
created by merging L1IFOparams.m with our knowledge of the 40m IFO. |
|
Fri Feb 15 22:16:04 2008, Andrey, Update, Computers, MATLAB is not working: "Licence checkout failed"
|
For some unknown to me reason,
Matlab stopped working about 20 minutes ago on all computers in the control room (both UNIX control machines and Windows).
It says: "License checkout failed. License Manager Error -15. MATLAB is unable to connect to the license server."
I do not know how to revive Matlab.
At the same time, I consider that I made a significant progress in building my theoretical/computational model in the last 2 days. I was able to compute the time-evolution of accelerometer signals through stacks and pendulums using Matlab command "lsim", and I am now able to calculate RMS of spectrum of differential arm length in different frequency intervals. It seemed to me that everything is ready in my program to make the three-dimensional theoretical/computational plot (RMS as a function of Q-factors of ETMX and ITMX), but unfortunately Matlab stopped working. It seemed to me that all that was remaining was to run a loop with all possible values of Q-factors. Let's hope that Matlab will be working after the weekend.
Andrey. |
|
Mon Feb 18 12:04:39 2008, Alberto, Update, Electronics, RF Monitor (StocMon)
|
I put the amplifiers next to the monitor on the PSL table, layed the power and the RF SMA cables out to the rack. I'm powering the box and the amplifiers with the power supply, waiting for someone to show me tomorrow how to connect it to the Sorensen (Steve, Ben?).
I'm ready to hook up the channels into EPICS. |
|
Tue Feb 19 10:14:13 2008, steve, Update, VAC, rga logging needs help
|
| The rga head and controller are running fine, but the data logging is not. |
|
Tue Feb 19 15:21:47 2008, Andrey, Update, SUS, Earthquake tripped watchdogs in ETMY, ITMY
|
According to the web-page http://earthquake.usgs.gov/eqcenter/recenteqsus/Quakes/ci14351140.php ,
there was a 5.0 earthquake in northern Baja California in Mexico at 02.41PM earlier today.
This earthquake made an effect on our watchdogs for ETMY and ITMY (their currents exceeded maximal values).
Watchdogs for ITMY are now restored back,
and it is taking more time for a "side degree" for ETMY to calm down,
it is still (40 minutes after the kick) swinging a lot with amplitude ~ 200mV. |
|
Tue Feb 19 18:28:41 2008, John, Update, PEM, More seismic in Baja California
|
Steve spotted more activity from the same quake.
Reset watchdog on ETMY. |
|
Wed Feb 20 11:34:17 2008, steve, Update, PSL, laser head temp is up
|
MOPA head temp is running at 20.3C now
Nomally it is at 18.5C |
|
Wed Feb 20 16:24:37 2008, steve, Update, PSL, the laser is recovering slowly
|
Head temp is still 20.5C and decreasing slowly.
Power output 2.9W
NPRO power 22 mW is increasing as head is cooling down |
|
Thu Feb 21 09:56:26 2008, steve, Update, PSL, the laser is back
|
The laser and the psl recovered.
The water chiller temp is 19.98C and head temp 18.4C
Power 3.2W
PMC_T 3.1
c1iovme was restarted and the mc is locking now |
|
Thu Feb 21 19:55:46 2008, rana, Update, Electronics, 2 BNC Cables, 1 Tee
|
I'm not sure where Ward and Miller went to Analyzer school, but it was probably uncredited.
I turned it on and used 2 BNC cables and a T to hook up the source to the 2 inputs and measured the always-exciting TF of cable.
Score: HP Analyzer 1
Rob & John 0
I have left the analyzer on in this complicated configuration. RTFM boys.
| Quote: | The HP 4195A network analyser may be broken, measurements below 150MHz are not reliable. Above 150MHz everything looks normal. This may be caused by a problem with its output (the one you'd use as an excitation) which is varying in amplitude in a strange way.
Analyzer |
|
|
Fri Feb 22 02:51:20 2008, Andrey, Update, PEM, Accelerometer ITMX seems to be broken
|
As people probably know,
I am trying (for a long time) to create a computational program that calculates the evolution of accelerometer time-domain data through stacks and pendulum transfer functions to test masses, and calculate the RMS of differential arm lenght spectrum.
I noticed on Tuesday that time-domain signals from the two accelerometers (one is near ETMX, the other one is near ITMX) seem to have different amplitudes of fluctuations around the mean value. I suspected that this is the main reason why I cannot get the awaited result of minimum of RMS for equal values of Q-factors for ETMX and ITMX suspensions (because we subtract two very different numbers, so we cannot get anything close to zero). I took amplitude spectra of the accelerometer data (dttfft2), and they look very differently for ETMX and ITMX accelerometers. I believe that spectrum of ETMX accelerometer represents seismic noise, but accelerometer ITMX seems to provide us with irrelevant and wrong data. No peaks, just almost monotoneous decreasing curve, and 10 times smaller amplitude. Therefore, ITMX seems to be broken.
I will try tomorrow to clap my hands, shout, yell, near the broken accelerometer to confirm that the accelerometer is broken (more precisely, that either accelerometer itself is broken,
or cable connections, or DAQ channel, but something is wrong). Now it is very late, and I am going home.
See attached figures: time-scale is 10^(-1), 10^0, 10^1, 10^2 Hz. |
|
Fri Feb 22 08:29:07 2008, Alberto, Update, Electronics, RF Monitor (StocMon)
|
| Quote: | I put the amplifiers next to the monitor on the PSL table, layed the power and the RF SMA cables out to the rack. I'm powering the box and the amplifiers with the power supply, waiting for someone to show me tomorrow how to connect it to the Sorensen (Steve, Ben?).
I'm ready to hook up the channels into EPICS. |
Me and Ben Abbot were plugging the cables that power that RF Monitor box into the PSL rack when inadvertently we made some arcs spark between the pins on the back of one of the ADC. Somehow that made the laser shut down although the MOPA stayed on. We also notice some smell of burn.
Later on, after several failed attempts, Rob, Ben and Steve could restart the laser. It took some times because the written procedure to start the chiller is not very precise. |
|
Fri Feb 22 08:33:18 2008, Alberto, Update, Electronics, RF Monitor (StocMon)
|
| Quote: | I put the amplifiers next to the monitor on the PSL table, layed the power and the RF SMA cables out to the rack. I'm powering the box and the amplifiers with the power supply, waiting for someone to show me tomorrow how to connect it to the Sorensen (Steve, Ben?).
I'm ready to hook up the channels into EPICS. |
With Ben, we hooked up the RF Monitor box into the PSL rack and created 4 EPICS channels for the outputs:
C1:IOO_RF_STOC_MON_33
C1:IOO_RF_STOC_MON_133
C1:IOO_RF_STOC_MON_166
C1:IOO_RF_STOC_MON_199
The power cable bringing +15V to the preamplifier on the PSL table should be replaced eventually. |
|
Fri Feb 22 11:11:00 2008, rob, Update, Electronics, REFLDD problem found
|
I used a network analyzer that actually works to find a problem in the REFLDD electronics chain. There was loose (=bad) SMA-BNC adaptor on the output of channel one of the HP RF Amplifier. It worked intermittently, so going onto the ISCT and fiddling with cables could sometimes temporarily fix the problem. The bad adaptor has been given to Andrey to discard. |
|
Fri Feb 22 11:13:15 2008, rob, Update, Electronics, RF Monitor (StocMon)
|
| Quote: | | It took some times because the written procedure to start the chiller is not very precise. |
It is actually very precise. Precisely wrong. |
|
Fri Feb 22 14:45:06 2008, steve, Update, MOPA, laser power levels
|
At the beginning of this 1000 days plot shows the laser that was running at 22C head temp
and it was send to LLO
The laser from LHO PA#102 with NPRO#206 were installed at Nov. 29, 2005 @ 49,943 hrs
Now,almost 20,000 hrs later we have 50% less PSL-126MOPA_AMPMON power |
|
Fri Feb 22 15:16:33 2008, Andrey, Update, PEM, ITMX Accelerometer is NOT broken
|
As I wrote in message 330, there was a bad signal from ITMX accelerometer. I have found the reason: the BNC-cable which goes from the black board with switches for accelerometer gain (1,10,100) towards DAQ-tower was completely disconnected from that black board with gain-switches. The end of the long BNC-cable was on the floor. Therefore, it was totally impossible to see any accelerometer signal. The cable that I am writing about should transport the signal from ITMX_X accelerometer.
Now all the BNC-connections seem to be in good shape, and spectra of accelerometers near ITMX and ETMX , both of them are in x-directions, are very much similar. |
|
Fri Feb 22 16:47:54 2008, rob, Update, Electronics, Baloney
|
Well I guess Rana didn't study too hard at Professor School, either. If he'd even bothered to actually read John's entry, he might have looked at the RF Out from the HP Analyzer. As it is, this experience so far has been like taking your car to a highly respected mechanic, telling him it's having acceleration problems, and then he takes a rag and wipes some dirt off the hood and then tells you "It's running fine. That'll be 500 bucks."
I make the current score:
Snarkiness: 2
Education: 0
I did RTFM, and it doesn't mention anything about crazy behaviour on the RF Output. So, I set up the analyzer to do a sweep from 500MHz to 1MHz, with output power of 0dBm, and plugged the output directly into the 300MHz scope with the input set to 50 Ohm impedance. The swept sine output looks totally normal from 500Mhz to 150MHz (measuring ~220mVrms below 300MHz -- 0dBm), where it abruptly transitions to a distorted waveform which the scope measures as having a frequency of ~25MHz and with 450mVrms (+6dBm). It then transitions again at some other part of the sweep to a cleaner-looking 25MHz waveform with ~1.2Vrms (+15dBm). See the attached Quicktime movie. The screeching in the background is the PSL door.
With this bizarre behaviour, it's actually possible that even someone who does everything carefully and correctly could break sensitive electronics with this machine. Let's get it fixed or get a new one.
Don't use the HP4195A anymore unless you want broken electronics.
| Quote: | I'm not sure where Ward and Miller went to Analyzer school, but it was probably uncredited.
I turned it on and used 2 BNC cables and a T to hook up the source to the 2 inputs and measured the always-exciting TF of cable.
Score: HP Analyzer 1
Rob & John 0
I have left the analyzer on in this complicated configuration. RTFM boys.
| Quote: | The HP 4195A network analyser may be broken, measurements below 150MHz are not reliable. Above 150MHz everything looks normal. This may be caused by a problem with its output (the one you'd use as an excitation) which is varying in amplitude in a strange way.
Analyzer |
|
|
|
Wed Feb 27 22:05:03 2008, John, Update, LSC, Auxiliary locking
|
A summary of the status of the auxiliary arm locking effort.
To help with lock acquisition we are attempting to independently lock the Y arm using light injected through ETMY. At present this secondary light source is an NPRO laser situated on the SP table. The laser light is transported to the ETM using a single mode optical fibre. In the future we might pick off some PSL light and apply a frequency shift.
We have been able to successfully mode match the fibre beam into the cavity and have been attempting lock the cavity using standard PDH signals (phase modulation sidebands are added to the light before it enters the fibre).
As yet no acceptable error signals have been produced. The demodulated RF signal is showing a time varying, bipolar dc offset.
We have minimised the residual amplitude modulation of the EOM but we expect small signals due to the undercoupled nature of the system, it could be that whatever RFAM still present is varying with time and causing this behaviour. We are also able to produce similar offsets by stressing (i.e. bending, shaking) the fibre. Could it be that the fibre is somehow converting PM into AM? Are we seeing etalon effects in the fibre or elsewhere?
If we cannot make any further progress with the existing setup we shall move the NPRO to the ETM table and try again. We are also looking into purchasing some other types of fibre.
Other things to consider are injecting through POY or using some other wavelength - neither seems obviously better.
Fiber, behavior |
|
Thu Feb 28 13:04:59 2008, rob, Update, VAC, rga logging working again
|
| Quote: | | The rga head and controller are running fine, but the data logging is not. |
It should run tonight at 1:25 AM. To get the cron job to work properly on op340m, I had to make wrapper sh script which defines the perl library before calling the actual RGAlogger script. |
|
Thu Feb 28 19:49:21 2008, rob, Update, Electronics, RF Monitor (StocMon)
|
| Quote: |
With Ben, we hooked up the RF Monitor box into the PSL rack and created 4 EPICS channels for the outputs:
C1:IOO_RF_STOC_MON_33
C1:IOO_RF_STOC_MON_133
C1:IOO_RF_STOC_MON_166
C1:IOO_RF_STOC_MON_199
The power cable bringing +15V to the preamplifier on the PSL table should be replaced eventually. |
I changed the names of these channels to the more appropriate (and informative, as they're coming from the RFAMPD):
C1:IOO-RFAMPD_33MHZ
C1:IOO-RFAMPD_133MHZ
C1:IOO-RFAMPD_166MHZ
C1:IOO-RFAMPD_199MHZ
I also added them in an aesthetically sound manner to the C1IOO_LockMC.adl screen and put them in trends. Along the way, I also lost whatever Alberto had done to make these monitors read zero when there's no light on the diode. It doesn't appear to be written down anywhere, and would have been lost with a reboot anyway. We'll need a more permanent & automatable solution for this. |
|
Mon Mar 3 09:25:33 2008, steve, Update, VAC, rga scan logging is working now
|
| Quote: |
| Quote: | | The rga head and controller are running fine, but the data logging is not. |
It should run tonight at 1:25 AM. To get the cron job to work properly on op340m, I had to make wrapper sh script which defines the perl library before calling the actual RGAlogger script. |
Thanks to Rob, it is working !
The baked, calibrated rga head
model# M206M, s/n #c128035 was reinstalled at the 40m ifo on Feb. 8, 2008
Faraday mode dwell time was increased from 2 to 16 sec
Rga head temp at top silver gaskit 45.2 C
The noise floor is at 1E-12 Torr
There is more detail in logbook VMI-14 p 107
pd65-m-d119 |
|
Mon Mar 3 13:58:10 2008, steve, Update, Computers, RFM Network are down
|
| The CODAQ_RFNETWORK are down, except C1SUSVME & AWG |
|
Mon Mar 3 19:34:40 2008, rana, Update, Computers, RFM Network are down
|
| Quote: | | The CODAQ_RFNETWORK are down, except C1SUSVME & AWG |
All of the FE machines were found to be down this afternoon. I called Alex and he suggested several
things which didn't work (restart EPICS tasks, power cycle RFM switch, etc.).
Then he suggested that I go around and power cycle every crate!!! And that sometimes the order of this
matters!!! I think he was just recording this conversation so that he could have a laugh by playing it on Youtube.
However, power cycling all of the FE crates seemed to work. Alex's theory is that 'something goes bad in the
RFM cards sometimes'.
Its all green now. |
|
Tue Mar 4 00:42:51 2008, rana, Update, Computers, FB0 still down ?
|
The framebuilder is still down. I tried restarting the daqd task and resetting the RFM
switch like it says in the Wiki but it still doesn't work right. The computer itself is
running (I can ssh to it) and the daqd process is running but there's a red light for
it on the RFM screen and dataviewer won't connect to it.
If Alex isn't over by ~10 AM, we should call him and ask for help. |
|
Tue Mar 4 10:08:21 2008, rob, Update, Computers, green lights unreliable when c0daqctrl down
|
So far I've tried powering off the framebuilder, power-cycling the RAID (it was showing an error message about bad IDE channel #4), and rebooting the LSC (just for fun). When I reset the LSC, its green light on the RFM_NETWORK screen did not turn red, making all these lights suspect. The iscepics40m process is what controls these red/green lights, so maybe it's gone wonky. It appears to be running however, on c1dcuepics, and it also seems to be functioning correctly in other ways (it's communicating correctly with the LSC).
Update: Alex and Jay came by. The solution was to reset the c0daqctrl processor, which apparently was not done in Rana's rebooting spree. Or maybe it needed to be done last. |
|
Wed Mar 5 17:35:24 2008, rana, Update, IOO, RFAM during MC lock
|
I used an ezcaservo command to adjust the offsets for Alberto's StochMon channels. They are all
at +2 V with no light on the RFAM PD (MC unlocked).
Then I looked at 5 minutes of second trend around when the MC locks. Since Alberto has chosen
to use +2V to indicate zero RF and a negative gain, there is a large RF signal when the StochMon
channels approach zero.
From the plot one can see that the RFAM for the 133 & 199 MHz channels is much worse than for the 33 and 166.
Its also clear that the turn on of the WFS (when the RFAMPD's DC light level goes up) makes the single demod
signals get better but the double demod get worse. |
|
Thu Mar 6 00:17:37 2008, rob, Update, Locking, DD handoff working
|
| Got the DD (double demod) handoff scripts working tonight, with just the DRMI. So, now acquisition with the single demod signals is working well, and handoffs to all double demod signals using the input matrix ramping worked several times with the scripts. Up next will be more work with the DRM+ARMs. |
|
Fri Mar 7 17:10:01 2008, Max Jones, Update, Computers, Noise Budget work
|
Noise budget has been moved to the svn system. A checked out copy is in the directory caltech. From now on, I will try to use the work cycle as outlined in the svn manual. Changes made today include the following:
getNoiseBudget
/matlab/noise/NoiseBudget
Details of the modifications made may be found on the svn system. Please let me know if anyone has a suggestion or concern. Thank you - Max. |
|
Mon Mar 10 02:05:08 2008, rob, Update, Locking, DRMI+2ARMs working better
|
Some encouraging progress on the locking front tonight. After the work on the DRM loops last week and a review of the settings for initial lock acquisition (loop gains, tickle amplitude, filter states, so on), the DRMI+2ARMS locking is working pretty well. That's to say, it takes from 5-15 minutes generally for the IFO to lock in the offset CARM state, with the arm powers at 0.5. It's then possible to raise the arm powers slightly, and handing off control of CARM to MCL works at low power, but engaging the AO path (using PO_DC as an error signal) is not working so well. Taking swept sines indicates that the PO_DC should be a good error signal. The next good thing to try might be just using PO_DC as an error signal for the length path, without using the AO path at all, to see if it's something in the hardware. |
|
Wed Mar 12 23:05:44 2008, rana, Update, IOO, MC WFS
|
they are bad, somewhat
please fix |
|
Thu Mar 13 12:11:58 2008, aivanov, Update, Computer Scripts / Programs, routing PEM -> ASS -> SUS_MCL
|
on ASS RFM 1 has PEM signals at
float at 0x100000 has c0dcu1 first ICS110B chan 1
float at 0x100004 has chan 2
etc.
ASS sends to RFM 0
float at 0x100000 goes to PRM MCL
0x100004 to BS MCL
0x100008 to IMTX MCL
0x10000c to ITMY MCL
0x100010 to SRM MCL
0x100018 to MC1 MCL
0x10001c to MC3 MCL
0x100020 to ETMX MCL
0x100024 to ETMY MCL |
|
Thu Mar 13 13:15:09 2008, aivanov, Update, Computer Scripts / Programs, new sfotware intall, backup files
|
New:
op440m:40m>ls -alt /cvs/cds/caltech/target/c1susvme[12]/*.o
-rw-r--r-- 1 controls staff 57920 2008-03-13 13:11 /cvs/cds/caltech/target/c1susvme2/losLinux2.o
-rw-r--r-- 1 controls staff 57976 2008-03-13 13:11 /cvs/cds/caltech/target/c1susvme1/losLinux1.o
op440m:40m>ls -alt /cvs/cds/caltech/target/c1isce[xy]/*.o
-rw-r--r-- 1 controls staff 246861 2008-03-13 13:12 /cvs/cds/caltech/target/c1iscey/losEtmy.o
-rw-r--r-- 1 controls staff 246861 2008-03-13 13:12 /cvs/cds/caltech/target/c1iscex/losEtmx.o
op440m:40m>ls -alt /cvs/cds/caltech/target/c0dcu1/*.o
-rw-r--r-- 1 controls staff 63547 2008-03-12 14:57 /cvs/cds/caltech/target/c0dcu1/dcuDma.o
Backups:
op440m:40m>ls -alt /cvs/cds/caltech/target/c1susvme[12]/*.o.13mar08
-rw-r--r-- 1 controls staff 55960 2005-06-21 13:30 /cvs/cds/caltech/target/c1susvme2/losLinux2.o.13mar08
-rw-r--r-- 1 controls staff 55960 2005-06-21 13:30 /cvs/cds/caltech/target/c1susvme1/losLinux1.o.13mar08
op440m:40m>ls -alt /cvs/cds/caltech/target/c1isce[xy]/*.o.13mar08
-rw-r--r-- 1 controls staff 229793 2007-03-08 11:09 /cvs/cds/caltech/target/c1iscex/losEtmx.o.13mar08
-rw-r--r-- 1 controls staff 229793 2007-03-08 11:09 /cvs/cds/caltech/target/c1iscey/losEtmy.o.13mar08
op440m:40m>ls -alt /cvs/cds/caltech/target/c0dcu1/*.o.12mar08
-rw-r--r-- 1 controls staff 60810 2004-09-08 08:47 /cvs/cds/caltech/target/c0dcu1/dcuDma.o.12mar08 |
|
Thu Mar 13 18:20:29 2008, John, Update, General, New Focus 4003 EOM 29.489MHz
|
I measured the modulation index as a function of drive power using an OSA. Agrees well with spec of 0.2 rad/V.
 |
|
Fri Mar 14 15:06:24 2008, rob, Update, Computer Scripts / Programs, routing PEM -> ASS -> SUS_MCL
|
| Quote: |
on ASS RFM 1 has PEM signals at
float at 0x100000 has c0dcu1 first ICS110B chan 1
float at 0x100004 has chan 2
etc.
ASS sends to RFM 0
float at 0x100000 goes to PRM MCL
0x100004 to BS MCL
0x100008 to IMTX MCL
0x10000c to ITMY MCL
0x100010 to SRM MCL
0x100018 to MC1 MCL
0x10001c to MC3 MCL
0x100020 to ETMX MCL
0x100024 to ETMY MCL |
You can differentiate between RFM 0 and RFM 1 in the simulink model by adding 0x4000000 to the offsets for RFM 1. |
|
Thu Mar 20 15:28:20 2008, steve, Update, VAC, tp2 's drypump replaced
|
| The fore pump of tp2 was replaced at fore line pressure 998m Torr |
|
Fri Mar 21 09:02:03 2008, steve, Update, VAC, tp 2 failed
|
Small turbo #2 is the forepump of the maglev.
It failed last night, shut down the maglev and interlock closed V1
Ifo pressure is 20 mTorr now. The Yarm was still locked at 8am this morning.
The PSL beam to MC was blocked just before the output periscope.
The psl mechanial shutter did not work from epic screen. |
|
Fri Mar 21 11:54:38 2008, rob, Update, VAC, tp 2 failed
|
| Quote: | Small turbo #2 is the forepump of the maglev.
It failed last night, shut down the maglev and interlock closed V1
Ifo pressure is 20 mTorr now. The Yarm was still locked at 8am this morning.
The PSL beam to MC was blocked just before the output periscope.
The psl mechanial shutter did not work from epic screen. |
The PSL mechanical shutter actually did trip last night, greatly confusing me and Rana. Not realizing that the software vacuum interlock had tripped, we manually re-opened the shutter. I'll modify the relevant MEDM screens to indicate when the EPICS interlock trips. |
|
Sun Mar 23 00:56:42 2008, John, Update, LSC, More on 3f
|
We ended our last attempt at 3f locking concerned about the beam size on PD6. I investigated tonight. The beam was not obviously overfilling the diode and a quick tweak of the steering mirror revealed a decent plateaux. Nevertheless we decided to try a different approach to see if we found the same problems as before on a different diode.
This time our 3f diode was Refl 33. I put a splitter on the output of the diode at the LSC rack sending one half into the usual refl 33 board, the other into refl DD 199 (which is demodulating at 99Mhz).
I got as far as handing off PRC to the 3f signal in lock. More work needed. |
|
Mon Mar 24 13:03:54 2008, rob, Update, Electronics, HP4195A is back
|
| Quote: | | The swept sine output looks totally normal from 500Mhz to 150MHz (measuring ~220mVrms below 300MHz -- 0dBm), where it abruptly transitions to a distorted waveform which the scope measures as having a frequency of ~25MHz and with 450mVrms (+6dBm). It then transitions again at some other part of the sweep to a cleaner-looking 25MHz waveform with ~1.2Vrms (+15dBm). |
The HP4195A is back from repair. At first, it exhibited exactly the same behaviour for which it was sent in for repair, and which is described above (pillage from entry 337). After speaking with the repair tech on the phone, who tried to imply that the digital scope was tricking us, I plugged the output into our HP8591E spectrum analyzer, just to have firm ammunition to combat the repair guy's looniness. This led to even weirder behaviour, like no output and overload signals on the inputs (with nothing connected). After turning the unit on and off several times, and firmly seating (and screwing in) the DB9 connectors in the back of the unit, it appears to be working properly. Except for a brief glitch as it passes through 150MHz, the swept sine signal now appears normal, both on the scope and in the spectrum analyzer.
Apparently the whole thing is due to a loose connection somewhere in the box, which wasn't actually fixed by the repair, but has at least been temporarily fixed by me stumbling around with a screwdriver and then pushing the power button a couple of times. |
|
Tue Mar 25 10:44:24 2008, rob, Update, Computers, c1susvme2
|
| Quote: | c1susvme2 isn't behaving itself. It keeps getting out of sync and/or giving a red status light.
After going through the usual restart procedures a few times (unsuccessfully) we power cycled the c1susvme & c1sosvme crates. We think everything came back okay.
We still can't get the status and CRC (cyclic redundancy check) to return to normal on c1susvme2. If Alex is around tomorrow please ask him to take a look. |
I rebooted it again this morning. The ASS machine is currently not running its process, for whatever reason (someone turn it off?). Let's leave it like this for a day and see how the c1susvme2 does. The other recent change is Steve's install of a cooling fan--maybe that's causing the problem. |
|