I await responses...
My inclination is to not do the writing of the matrices automatically nor to do the weekly kicks. Its nice to have long locks of the MC, etc.
I suggest just making the kick on Sundays when someone intentionally asks for it (e.g. by pressing a button on Friday). The free-swinging ringdown ought to be a opt-in kind of feature, not opt-out.
Ok, here's the deal:
So, here is an example of how this works:
The code is set to run tomorrow morning. Everything but the writing will be done.
As we have seen in the past, both of the ITMs were more dusty than the ETMs, presumably because we have the vertex open much more often than the ends. Kiwamu and I wiped all of the optics until we could no longer see any dust particles within a ~1.5 inch diameter area around the center.
Since we have ITMX out for magnet gluing, I'll probably drag wipe both front and back surfaces before putting it back in the suspension cage. All of the optics have clear dust on the AR surfaces, but we can't get to that surface while the optics are suspended. For the ETMs this isn't too big of a deal, but it does concern me a bit for the ITMs and other transmissive optics we have. I don't think it's bad enough yet though to warrant removing optics from suspensions just to wipe them.
The on/off switch for the drill press is broken. Replacement parts should be here tomorrow.
Drill press is all better now. A spare switch is in the top drawer with the drill bits.
With the help of an expansion card, I verified that the + 15V and + 24V from the eurocrate in the slot I've identified for the PZT driver boards are making their way to the board. The slot is at the right-most end of the eurocrate in 1Y4, and the rack door was getting in the way of directly measuring these voltages once I hooked up the driver board to the expansion card. So I just made sure that all the LEDs on the expansion card lit up (indicating that the eurocrate is supplying + 5, + 15 and + 24V), and then used a multimeter to check continuity between the expansion card and the driver board outside of the eurocrate. The circuit only uses + 15V and + 24V, and I checked for continuity at all the IC pins marked with these voltages on the schematic.
Since the whole point of this test was to see if the slot I identified was delivering the right voltages, I think this is sufficient. I will now need to fashion a cable that I can use to connect a DC power supply to the PZT driver boards so that these can be tested further.
The high voltage points (100V DC) remain to be tested.
I have installed Dropbox on the 40m workstations, using the foteee account.
I put it in /users/Dropbox.
As a side note, I did the install while sitting on Pianosa, but since I put the folder on the mounted hard drive, I think we should be able to use it from any workstation, although I have not yet confirmed this.
This morning I and Steve replaced the dry fore pump of TP3, which is located under the y-arm.
After replacing it we confirmed vacuum normal condition. The fore line pressure of TP3 went down to 11 mTorr from 750 mTorr
Attached picture is new pump after setup.
I'm turning the sus damping off for Dsub connection fix at the back of 1X5 rack
The plan is to install 4-40 jack screws to lock connector positions.
All dewittening(or called coil driver) and wittening D sub connectors are locked with two 4-40 socket head screws
I was thinking tonight about more possible reasons that our PRC sucks, and I wonder if dust on the BS could create the problem.
Historically, Kiwamu and I found a few dust particle scattering centers every time we inspected the test masses before drag wiping. Sometimes, there would be one frustratingly close to the center of the optic. I'm not sure if we ever made note of how many we saw and where they were, except out loud to the assembled crowd.
Anyhow, the BS is the only IFO optic that was not replaced, so I'm not sure how long it has been since it was cleaned. If the PR-flat cavity looks okay and we take out the BS to do a PRM-ITMY cavity, we should inspect the beam splitter.
Also, the PRM could need cleaning, but at least it has been drag wiped within recent memory.
My question is, could a few scattering centers cause the behavior that we are seeing?
EDIT: List o' elogs....
Elog 5301 - Some details on dust seen on ITMs and ETMs, Aug 2011.
Elog 4084 - Kiwamu's in-situ drag wiping how-to, with details on some of the dust we saw. Dec 2010.
Elog 3736 - PRM drag wiped before suspension (Oct 2010)
Elog 3111 - June 2010, BS drag wiped.
RFpds box is moved from RF cabinet E4 to clean cabinet S15
Inventory updated at https://wiki-40m.ligo.caltech.edu/RF_Pd_Inventory
Large Area InGaAs PIN Photodiode -- C30642GH 6 pieces in stock
Large Area InGaAs PIN Photodiode with a 2,0 mm active diameter chip in TO-5 package with flat glass window
Large area InGaAs PIN photodiode with useful diameter of 2,0 mm in a T0-5 package with a flat glass window. The C30642GH provides high quantum efficiency from 800nm to 1700nm. It features high responsivity, high shunt resistance, low dark current, low capacitance for fast response time and uniformity within 2% across the detector active area.
ELOG reverted to 2.7.5 due to editing difficulties
- /cvs/cds/caltech/elog/start-elog.csh reconfigured to launch 2.7.5
- /cvs/cds/caltech/elog/elog is linked to ./elog-2.7.5
- logbook dir of 2.8.0 was copied in the dir of 2.7.5. The old and obsolete 2.7.5 was discarded.
ELOG reverted to 2.7.5 due to editing difficulties
I think I had the same problem when I switched to 2.75 from 2.65.
Then the problem was FCKeditor.
We should try the solution I put in the elog page of the wiki.
ELOG restarted with 2.8.0 again.
- moved elog-2.8.0/script dir to elog-2.8.0/script.orig
- copied elog-2.7.5/script to elog-2.8.0/script
- /cvs/cds/caltech/elog/start-elog.csh reconfigured to launch 2.8.0
- /cvs/cds/caltech/elog/elog is linked to ./elog-2.8.0
- logbooks on 25th and 26th were copied from 2.7.5 to 2.8.0.
I've installed the very fresh ELOG 3.0, for nothing else than the new built in text editor which has a LATEX capable equation editor built right in.
Check out this sweet limerick:
gcc -L/usr/lib/ -ldl -lresolv -lm -ldl -lnsl -lsocket elogd.c -o elogd
A few things that I have neglected to ELOG yet:
scripts/offsets/LSCoffsets is a new script that uses ezcaservo to set FM offsets of our LSC PDs. It still warns about large changes, and lets you revert. It reads the FM gain to pick the right gain for the ezcaservo call.
MC refl DC was all over the place today, and has recently been "fuzzier" on the wall StripTool than I like. I touched the MC2 pointing a little bit, and the WFS seemed to find a sweet spot where the refl got steady back at around and under 0.5. I then ran "offload WFS" to try and stay there.
Incidentally, the PMC transmission drifted up to 0.81 at some point today. This is weird, since not too long ago, we were not able to reach this level even with careful alignment. This coincided with the MC power being back up to ~17k, and arms locking at around 0.95.
Last week I quickly tried cranking up the x-end green modulation frequency to ~1.3MHz (corresponding to a notch in the PZT AM response), and using a 550k lowpass on the mixer output, instead of a 70k, to try to buy more phase and increase the UGF. It didn't work. I didn't have a way to tune the mixer phase angle, and the mixer output was super noisy, but there were instants where I could convince myself that a mode was briefly locked to the arm... I'm going to do the Right Thing and characterize the loop properly, to figure out how to get at least 10kHz of control bandwidth out of these things.
This morning I found that Google bot crashed the elog again. I started the investigation and found the threaded mode is fine if we use the recent 10 entries.
I gradually copied the old entries to a temporary elog and found that a deleted elog entry on August 6 had a corrupted remnant in the elog file. This kept crashed the threaded mode.
Once this entry has been eliminated again, the threaded mode got functional.
I hope this eliminates those frequent elog crashing.
Google bot crashed the elog again. Then, I found that Google bot (and I) can crash elogd by trying to show the threaded view.
There looks similar issue reported to the elog forum, the author did not think this is a true bag.
Note: This happens only for the 40m elog. The other elogs (ATF/PSL/TCS/SUS/Cryo) are OK for the threaded view.
Did it again. It seemed that Google bot came to the elog and tried to obtain "http://nodus.ligo.caltech.edu:8080/robots.txt". That was the last of the log.
Bot came from the AJW's homepage. Also Google FeedFecther came to the elog.
With Dave Barker's help, I changed the elog startup script. Instead of running as a Daemon with the -D option,
it now runs in the background with the unix "&". I think that the stdout and stderr are now redirected to a log file called elog.log.
We can 'tail -f' this file to see what its up to and debug any future crashing.
No elog response from outside and no elogd process on nodus, so I restarted it using 'start-elog.csh'.
I measured coherence between 2 EM 172 microphones in a "quiet room" with SR785
High-frequency noise (>2k) is SR785 noise - I'm not using any amplifier now, the signal from microphone is sent directly to SR785 and is weak at high frequencies.
I've put EM 172 microphones inside Steve's isolation box to measure their noise. I've attached mics to each other and aligned them using the tape.
At low frequencies (below 1 Hz) the noise is limited by ADC as there is a 10 Hz high-pass filter inside mic readout box.
ADC noise is measured by splitting the signal from 1 mic into 2 ADC channels.
At low frequencies (below 1 Hz) the noise is limited by ADC as there is a 10 Hz high-pass filter inside mic readout box.
BT EM172 microphones are ordered.
I've checked new small EM172 microphones for nonlinearities using Koji's Mac Book speakers. EM172 + Mac nonlinearities are presented at the figure
The Mac's sound frequency was specified to be 500 Hz. Harmonics are seen at 1k, 1.5k, but their amplitude is ~30 times less.
I recreated Den's microphone amplifier circuit on a solderless breadboard to test it and make sure it does what it's supposed to. So far it seems like everything is working- I'll do some testing tomorrow to see what the amplified output is like for some test noises. Here's the circuit diagram that Den made (his elog as well https://nodus.ligo.caltech.edu:8081/40m/6651):
I'm not sure why he set up the circuit the way he did- he has pin 7 grounded and pin 4 going to +12V while in the datasheet for the opamp (http://cds.linear.com/docs/en/datasheet/1677fa.pdf), pin 7 goes to positive voltage and pin 4 goes to negative voltage. There's some other strange things about the circuit that I don't really understand, such as the motivation for using no negative voltage source, but for now I'm going to stick with Den's design and then make some modifications after I have things working and a better understanding of the problem.
Here's my current plan:
-Make sure Den's amplifier works, test it out and make changes if necessary
-Make multiple amplifier circuits on soldering breadboard
-Either make a new amplifier box or reuse Den's old box depending on how many changes I make to the original circuit
-Solder EM172s to BNC connectors, set them up around the floor suspended
-Get the amplifier box hooked up, set up some data channels for the acoustic noise
-Add new acoustic noise tab to the summary pages
Den also mentioned that he wanted me to measure the coupling of acoustic noise to DARM.
Found 60 EM172 microphones. Previous elog with details: 7777.
Gautam and Steve,
It is hanging in the midle of the PSL enclosure. Wired to 1X1 to get plus and minus 15V through fuse. It's output is connected to FB c17 input.
GV: C17 corresponds to "MIC 1" in the PEM model. So the output is saved as "C1:PEM-MIC_1_OUT_DQ"
I added an EM172 to my soldered circuit and it seems to be working so far. I have taken a spectra using the EM172 in ambient noise in the control room as well as in white noise from Audacity. My computer's speakers are not very good so the white noise results aren't great but this was mainly to confirm that the microphone is actually working.
I don't know if anyone looked at the time series (not trend) or spectrum of the Microphone after installation, but it looks bad and featureless to me. Is the Microphone broken?
This shows the spectrum from early this morning and again from tonight. You can see that it is bi-stable in its noise properties. This thing is busted; we're now removing it from the PSL so that it doesn' light it self on fire.
I had noticed something wonky with the microphone, but neglected to elog it. I had tested it after installation by playing a sine wave from my laptop and looking at the signal on the PSL table, it worked fine. But you can see in the attached minute trend plot that the signal characteristics changed abruptly ~half a day after installation, and never quite recovered.\
Monitoring good, but remember that the EOM alignment must be done carefully to minimize the RAM before we can use these trends.
I temporarily diverted the output of the RAMmon PD to a spectrum analyzer (4195 in Spectrum Analyzer mode), and tweaked the EOM alignment until I minimized the 11 and 55 MHz peaks as much as possible. It was possible to get each individual peak to disappear into the noise (about -70dBm), but to get both minimized simultaneously I wasn't able to get both down into the noise. I left the 11MHz at about -55dBm, and the 55MHz at about -60dBm. If Kiwamu's simulation tells us that one is more significant than the other (55, because we use it for MICH?), then we can decide to favor putting that peak in the noise and sacrifice ~10dB in the other peak.
When I first plugged the PD into the analyzer, I saw 22MHz and 44MHz (small) peaks, but they went away after the first bit of tweaking.
Before having used the analyzer, I was trying to minimize the demodulated signals via StripTool, but that was a slow process. The spectrum analyzer was obviously much faster.
The PD has been returned to the regular RAMmon electronics.
Next up: putting in the new demod box that Koji tested last night.
I disconnected the heater at ~2:20 UTC, leaving the sensor circuit operational. Don't be fooled by the apparent railing of the heater in the monitor trace below---the heater has been physically disconnected, so there is no current flowing even though the servo is railed (since the error signal is huge with the loop open).
Kiwamu and I also restarted c1sus and locked the MC so that we can get some uncontrolled Stochmon data. I think he is planning to reconnect the heater some hours from now so that we can get yet another controlled data stretch (since the first one was cut short by c1sus's going down).
I was preparing for the aLIGO EOM measuement to be carried out tomorrow afternoon.
I did a few modifications to the PLL setup.
Tomorrow I am going to modulate the EOM with the AUX Marconi via an amplifier (probably)
Automated scripts (AGinit.py and AGmeas.py) are in /users/koji/scripts
I will revert the setup once the measurement is done tomorrow.
Rich and I worked on the EOM measurement. After the measurement, the setup was reverted to the nominal state
I have drilled all the holes necessary, and have tapped all but 4 of the holes for the new EOM mount. The adapter plate is finished and ready to go (including a 10-min iso sonic bath). The riser that goes between the table and the 9082 mount is drilled but not yet tapped.
[Mirko / Kiwamu]
The resonant box has been installed together with a 3 dB attenuator.
The demodulation phase of the MC lock was readjusted and the MC is now happily locked.
We needed more modulation depth on each modulation frequency and so for the reason we installed the resonant box to amplify the signal levels.
Since the resonant box isn't impedance matched well, the box creates some amount of the RF reflections (#5339).
In order to reduce somewhat of the RF reflection we decided to put a 3 dB attenuator in between the generation box and the resonant box.
(what we did)
+ attached the resonant box directly to the EOM input with a short SMA connector.
+ put stacked black plates underneath the resonant box to support the wight of the box and to relief the strain on the cable between the EOM and the box.
+ put a 3 dB attenuator just after the RF power combiner to reduce RF reflections.
+ readjusted the demodulation phase of the MC lock.
(Adjustment of MC demodulation phase)
The demodulation phase was readjusted by adding more cable length in the local oscillator line.
After some iterations an additional cable length of about 30 cm was inserted to maximize the Q-phase signal.
So for the MC lock we are using the Q signal, which is the same as it had been before.
Before the installation of the resonant box, the amplitude of the MC PDH signal was measured in the demodulation board's monitor pins.
The amplitude was about 500 mV in peak-peak (see the attached pictures of the I-Q projection in an oscilloscope). Then after the installation the amplitude decreased to 400 mV in peak-peak.
Therefore the amplitude of the PDH signal decreased by 20 %, which is not as bad as I expected since the previous measurement indicated 40 % reduction (#2586).
Here is 5 days of trend of the EOM temp sensor and the heater driver monitor. Unfortunately, it looks like we're regularly railing the heater. Not so awesome.
Can you zoom the temp mon? (V= -0.1 ~ +0.1)
The crystal was too cold and I tried to heat the PSL table by the lighting. But it seemed in vain.
I have modified the EOM temperature sensor circuit for the temperature vs. RAM long-term measurements. The only real change is that the sensor is a 100-kOhm thermistor, instead of a 100-Ohm RTD. These semiconductor thermistors (DigiKey P/N 317-1377-ND) are highly nonlinear and can be much more responsive than RTDs, but this difference is much more noticeable at low temperatures.
Frank had told me that the fractional response of the thermistors was so much higher that I could scale the bridge drive current down by the same factor as the resistance was increasing (i.e., 1 mA -> 1 uA, commensurate with 100 ohms -> 100k) and still see a marked improvement. It turns out that at room temperature for this particular sensor the gain enhancement would only be about ~10x, so I only reduced the drive current to ~10 uA, by INCREASING the drive voltage from ~0.1 V -> 1 V, improving the enhancement to ~100x.
Below is a plot of the real nonlinear response of the thermistor, along with a linear approximation at 298.15 K, which gives a coefficient of ~ -4.67 kOhms/K. The differential bridge output voltage response for the new resistance and current is ~7.5 uV/Ohm 2.5 uV/Ohm, bringing the total temperature response before amplification to ~35 mV/K 11.6 mV/K. Looking at a trend of the FSS_RMTEMP channel over a month, we saw that the maximum PSL table temperature fluctuations were ~2 Kpp, so we aimed the maximize resolution by matching +/- 2 K with +/-10 V at the ADC. This was done by using a gain of ~300 in the AD620 that amplifies the differential bridge output. We found that a gain of ~300 put it pretty close, so the grand total calibration ~ 10.5 V/K 3.5 V/K.
Edit (ZK): I screwed up with calculating the bridge response by a factor of three somehow, so I have stricken and restated the calibrations above
I took a look at the recently acquired temperature data alongside the RAMmon 11 and 55 signals, and it appears that we're seeing the same sort of fringing effects we usually see, with oscillatory RAM levels for a monotonic change in EOM temperature.The odd bit towards the end is caused by the MC losing lock.
It is going to be very interesting to find out what causes this fringing.
Activities in a far, far away land called PSL lab...
We are looking at the RFAM from the detuned ACAV refl pd in the red trace. Red trace is the demodulated RFAM output. RCAV was locked, so on a ~min time scale the freq drift follows, so we stay detuned.
Heater and temp sensor are taped to EOM, no foam box.
Around when the red trace starts, we turn on the heater to stabilize the temp. After a while we reach the set point (no longer railing the heater), and start seeing temp stabilization. The RFAM fluctuations clearly go down. Neato.
No calibrations, no RIN, no nothing. Get over it.
Green trace is the DC level of a different PD, which should also be sensitive to RFAM.
This is using a fancy-pants temp controller chip that Frank found. It works, so that's handy.
I inspected the temperature stabilization circuit today to see why it wasn't working. It didn't make sense that it just kept railing the heater even though the error signal was negative (which should turn the heater current OFF).
It turns out that the LF356 (FET-input op amp) that serves as the filter stage for the heater driver was broken---I measured a full, railed positive output even though the input was negative. We didn't have any more LF356s, so I replaced it with an OPA604 (Burr-Brown FET-input), and all seemed to work fine.
Since we were having too much digitization noise, I also added a temperature monitor buffer using a non-inverting OP27 circuit with G=99. This makes the overall calibration ~7.6 V/K into the ADC.
Below is a time series showing that it is working. The circuit was turned on near the beginning, and you can see that the heater is railed at +10V until shortly after the error signal goes negative, at which point it adjusts and ultimately approaches a steady-state value of ~7.8V.
I have no figures to demonstrate this, but it seems that even with this 100x increase in monitor gain, the error signal is still below the ADC noise level. This could be because the ambient temperature fluctuations are just that small on timescales of less than a few hours. I'm not sure if we really need to be able to see the temperature noise level above a few mHz, but if we do we will have to find some way to increase our dynamic readout range.
Also, Koji told me where he stashed the nice protoboards, so I will get onto transferring this circuit onto one ASAP. Since it is working now, I think I'll leave it until after the TAC.