this afternoon we centered the optical levers for all the optics.
To do that we first ran the alignment scripts for all the cavities.
ITMX Pitch: 142 microrad/counts
ITMX Yaw: 145 microrad/counts
ITMY Pitch: 257 microrad/counts
ITMY Yaw: 206 microrad/counts
ETMX Pitch: 318 microrad/counts
ETMX Yaw: 291 microrad/counts
ETMY Pitch: 309 microrad/counts
ETMY Yaw: 299 microrad/counts
BS Pitch: 70.9 microrad/counts
BS Yaw: 96.3 microrad/counts
PRM Pitch: 78.5 microrad/counts
PRM Yaw: 79.9 microrad/counts
SRM Pitch: 191 microrad/counts
SRM Yaw: 146 microrad/counts
After looking at some oplev noise spectra in DTT, we discovered that the ETMY quad (serial number 115) was noisy. Particularly, in the XX_OUT and XX_IN1 channels, quadrants 2 (by a bit more than an order of magnitude over the ETMX ref) and 4 (by a bit less than an order of mag). We went out and looked at the signals coming out of the oplev interface board; again, channels 2 and 4 were noise compared to 1 and 3 by about these same amounts. I popped in the ETMX quad and everything looked fine. I put the ETMX quad back at ETMX, and popped in Steve's scatterometer quad (serial number 121 or possibly 151, it's not terribly legible), and it looks fine. We zeroed via the offsets in the control room, and I went out and centered both the ETMX and ETMY quads.
Attached is a plot. The reference curves are with the faulty quad (115). The others are with the 121.
I adjusted the ETMY quad gains up by a factor of 10 so that the SUM is similar to what it was before.
Tonight I centered the oplevs for ITMX/Y, SRM, PRM, BS.
After doing that I noticed that the BS drifted a little from where I had set it.
I measured the ETMY oplev beam size at a couple different distances away from the HeNe by taking out the steering mirror and letting the light propagate a ways. I put the steering mirror back, aligned the oplev, and was able to relock the Yarm, so I think it's all back as it has been the last couple of weeks.
Now I need t o do some geometry and ray-tracing matrices to decide what focal length lens to buy, then we'll have a shiny new ETMY oplev.
ETMY oplev is currently a work in progress. The HeNe beam is hitting the photodiode, but the spot size there is pretty much the size of the entire QPD. Thus, the ETMY oplev isn't really useful right now. I'm re-figuring things out (note to self: close to the laser, you have to use Gaussian optics...regular ray tracing doesn't really work), and hopefully will have the oplev back under control by the time Alberto is finished realigning the IFO, so this doesn't keep anyone from doing any exciting locking work.
ETMY oplev is still out of order. Hopefully I'll get it under control by tomorrow.
We aligned the full IFO, and centered all of the oplevs and the IP_POS and IP_ANG QPDs. During alignment of the oplevs, the oplev servos were disabled.
Koji updated all of the screenshots of 10 suspension screens. I took a screenshot (attached) of the oplev screen and the QPD screen, since they don't have snapshot buttons.
We ran into some trouble while aligning the IFO. We tried running the regular alignment scripts from the IFO_CONFIGURE screen, but the scripts kept failing, and reporting "Data Receiving Error". We ended up aligning everything by hand, and then did some investigating of the c1lsc problem. With our hand alignment we got TRX to a little above 1, and TRY to almost .9 . SPOB got to ~1200 in PRM mode, and REFL166Q got high while in DRM (I don't remember the number). We also saw a momentary lock of the full initerferometer: On the camera view we saw that Yarm locked by itself momentarily, and at that same time TRX was above 0.5 - so both arms were locked simultaneously. We accepted this alignment as "good", and aligned all of the oplevs and QPDs.
It seems that C1LSC's front end code runs fine, and that it sees the RFM network, and the RFM sees it, but when we start running the front end code, the ethernet connection goes away. That is, we can ping or ssh c1lsc, but once the front end code starts, those functions no longer work. During these investigations, We once pushed the physical reset button on c1lsc, and once keyed the whole crate. We also did a couple rounds of hitting the reset button on the DAQ_RFMnetwork screen.
A "Data Receiving Error" usually indicates a problem with the framebuilder/testpoint manager, rather than the front-end in question. I'd bet there's a DTT somewhere that's gone rogue.
We restarted daqd and it did restored the problem
Then restart the 'daqd' process:'telnet fb40m 8087', type "shutdown" at the prompt. The framebuilder will restart itself in ~20s.
telnet fb40m 8087
It did not related to the problem, but we also cleaned the processes related to dtt, dataviewer by pkill
After that the alignment scripts started to work again. As a result, we got some misalignment of the oplevs.
I am going to come on Sunday
- Align the optics
- Align the oplevs again
- Take snapshots for the suspensions
- Align the IP_POS, IP_ANG
- Align the aux laser for the absolute length
- Align PSL table QPDs, and MCT QPD
NOTE: HEPA is on at its full.
[[[OK]]] Align the suspended optics (by Rob)
[[[OK]]] Align the oplevs again
[[[OK]]] Take snapshots for the suspensions/QPDs/IO QPDs/PZT strain gauges
[[[OK]]] Align the IP_POS, IP_ANG
[[[OK]]] Align the PSL table QPDs, the MC WFS QPDs, and the MCT QPD
[[[OK]]] Align the aux laser for the absolute length
Align the suspended optics (by Rob)
Align the oplevs again
Take snapshots for the suspensions/QPDs/IO QPDs/PZT strain gauges
Align the IP_POS, IP_ANG
Align the PSL table QPDs, the MC WFS QPDs, and the MCT QPD
Align the PSL table QPDs, the MC WFS QPDs, and the MCT QPD
Align the aux laser for the absolute length
o Go to only ITMX mode:
Save the alignment of the mirrors. Activate X-arm mode. Misalign ITMY and ETMX.
o Inject the aux beam:
Open the shutter of the aux NPRO. Turn the injection flipper on.
o Look at the faraday output:
There are several spots but only one was the right one. Confirm the alignment to the thorlabs PD. Connect the oscilloscope to the PD out with a 50Ohm termination.
Thanks to the Alberto's adjustment, the beat was already there at around 10MHz. After the PD adjustment, the DC was about 600mV, the beat amplitude was about 50mVpp.
o Adjust the aux beam alignment:
Adjust the alignment of the aux beam by the steering mirrors before the farady isolator. These only change the alignment of the aux beam independently from the IFO beam.
After the alignment, the beat amplitude of 100mVpp was obtained.
Close the shutter of the NPRO. Turn off the flipper mirror. Restore the full alignment of the IFO.
I set up instant green oplevs for ITMs.
A green laser pointer has been set on each end table. It illuminates the ITM center. The beam goea through the ETM substrate.
The reflected green beam returns to the ETM if the ITMs are aligned. Even though the reflected beam to the end is too big, this can
be a rough reference for each ITM.
Note: The green laser pointer at the ETMX were borrowed from Frank. We must return it to him when we finish the work.
1) Goto http://localhost:631/
2) Click on "Add Printer"
3) Choose HP JetDirect
4) Use the correct address (socket://220.127.116.11:9100)
5) Choose HP and the 5550 postscript driver as the options
6) Try to only print useful stuff and not kill too many trees.
We were stymied tonight by a problem which began late this afternoon. The MC would periodically go angularly unstable, breaking lock and tripping the MC2 watchdogs. Suspicion fell naturally upon McWFS.
Eventually I traced the problem to the MC3 SIDE damping, which appeared to not work--it wouldn't actually damp, and the Vmon values did not correspond to the SDSEN outputs. Suspicion fell on the coil driver.
Looking at the LEMO monitors on the MC3 coil driver, with the damping engaged, showed clear bit resolution at the 100mV level, indicating a digital/DAC problem. Rebooting c1sosvme, which acquires all the OSEM sensor signals and actually does the side damping, resolved the issue.
Lies! The problem was not resolved. The plot shows a 2-day trend, with the onset of the problem yesterday clearly visible as well as the ineffectiveness of the soft-reboot done yesterday. So we'll try a hard-reboot.
So, it appears that one doesn't even have to change the Marconi set frequency to alter the phase of the output signal. It appears that other front panel actions (turning external modulations on/off, changing the modulation type) can do it as well. At least that's what I conclude from earlier this morning, when after setting up the f2 Marconi (166MHz) for external AM, the double-demod handoff in the DRMI no longer worked. Luckily this isn't a real problem now that we have the setDDphases and senseDRM scripts.
The real problem is that we are using frequency synthesizers to make the beat signals (133 and 199) instead of mixers. Luckily, the future 40m will not use beat signals (?) or synthesizers.
I ran the armLoss script for both Xarm and Yarm. The results are confidential, pending the completion of Alberto's cavity pole/finesse measurement due to the 'bet' as to what the new losses are after the drag wiping.
If you're the kind of person who likes to look at their Chrismas presents, the log files with the results are in the usual place for this script: /scripts/LSC/loss-ARM-GPStime.log (loss-Y-944865071.log and loss-X-944865946.log)
I checked the situation from my home and the problem was solved.
The main problem was undefined state of the autolocker and the strange undefined switch states, being associated with the bootfest and burtrestore.
- MC UP/DOWN status shows it was up and down. So I ran scripts/MC/mcup and scripts/MC/mcdown. These cleared the MC autolocker status.
- I had a problem handling the FSS. After mcup/mcdown above, I randomly pushed the "enable/disable" buttons and others, and with some reason, it recovered the handling. Actually it acquired the lock autonomously. Kiwamu may have also been working on it at the same time???
- Then, I checked the PSL loop. I disconnected the loop by pushing the "test" button. The DC slider changes the PZT voltage only 0~+24V. This is totally strange and I started pushing the buttons randomly. As soon as I pushed the "BLANK"/"NORMAL" button, the PZT output got back under the control.
- Then I locked the PMC, MZ, and MC as usual.
Alberto: You must be careful as the modulations were restored.
It's been an iffy last few hours here at the 40m. Kiwamu, Koji and I were all sitting at our desks, and the computers / RFM network decided to crash. We brought all of the computers back, but now the RefCav and PMC don't want to lock. I'm a wee bit confused by this. Both Kiwamu and I have given it a shot, and we can each get the ref cav to sit and flash, but we can't catch it. Also, when I bring the PMC slider rail to rail, we see no change in the PMC refl camera. Since c1psl had been finicky coming back the first time, I tried soft rebooting, and then keying the crate again, but the symptoms remained the same. Also, I tried burt restoring to several different times in the last few days, to see if that helped. It didn't. I did notice that MC2 was unhappy, which was a result of the burtrestores setting the MCL filters as if the cavity were locked, so I manually ran mcdown. Also, the MC autolocker script had died, so Kiwamu brought it back to life.
Since we've spent an hour on trying to relock the PSL cavities (the descriptive word I'm going to suggest for us is persistent, not losers), we're giving up in favor of waiting for expert advice in the morning. I suppose there's something obvious that we're missing, but we haven't found it yet......
This is a (sort of) known problem with the EPICS computers: it's generally called the 'sticky slider' problem, but of course it applies to buttons as well. It happens after a reboot, when the MEDM control/readback values don't match the actual applied voltages. The solution (so far) is just to `twiddle' the problematic sliders/button. There's a script somewhere called slider_twiddle that does this, but I don't remember if it has PSL stuff in it. A better solution is probably to have an individual slider twiddle script for each target machine, and add the running of that script to the reboot ritual in the wiki.
Steve showed me how to send an international fax today:
Alberto is visiting us from Australia. He brought some terrific presents. It is going to be very demanding task to wait for the rest of the 40m team
to return from Wales to taste coffee: PNG Peaberry of Wagonga, Monsooned Malabar of Jindebah and Signature Blue Blend of Cosmorex.
We have placed some sweet giant strawberries in the fridge; free for eating for anyone working in the lab today or tomorrow:
Trying to take an image or movie of the ETMY Transmon cam, we got instead this attached image.
I think it is just some scattered green light, but others in the control room think that it is a message from somewhere or someone...
It is not an angel, it is clearly a four leaf clover (also known as "quadrifoglio"). It is very rare, it brings good luck!
Last week Rana and I struggled to figure out how to un-full-screen windows on the Ubuntu workstations that appeared to be stuck in some sort of full screen mode such that the "Titlebar" was not on the screen. Nothing seemed to work. We were in despair.
Well, there is now hope: it appears that this really is a "fullscreen" mode that can be activated by hitting F11. It can therefore easily be undone by hitting F11 again.
The summery pages are working at a slow motion speed. It's response time 12 minutes.
I'm planning to remove the ETMY optical table enclosure and move it over to CES Shop 8am Thursday morning.
We'll install spring loaded lathes, hooks and quick release pins.
The bridge will be reinforced with steel plate to support release pins on posts.
There will be an other cut out for cable feedtrough as it is shown on elog #8472
Let me know if this timing does not fit your work.
The bridge support posts were shimmed today. Surgical tubing 402R - o - rings were glued togeather with " instant krazy glue "
Atm2 Carey CH-3540 latches are compressed ~2.5 mm in the clamped position.
Atm3 is showing the captured quick release pin in the steel reinforced bridge that is supported by the post. It works great. The post screw is sealed by o-ring. The quick-pin is sealed by an epoxy attached copper cap.
Atm4 Enclosure is on it's back. Bottom o-ring can be seen. The hole reinforced bridge structure is visible.
Now I'm working on the window connection to the chamber. I'm very close leak checking this box.
In case of leaking around the top tubing seals we have two options:
a, cut down on the cover rim by 0.040" or b, increase tubing diameter
Temporary oplev in place. The spot on the qpd is still big. My two lens solution did not work.
I will finalize optical component position of the oplev after the the arm transmitted and green beam optics in place. They have priority.
Oplev spot size on qpd ~ 1 mm
PS: I realized it later that the returning beam is going through a lens for TRY. This is a nono.
This beam path will be relayed again as the TRY, green beam and IP-ang get there place.
Oplev spot size on qpd ~ 1 mm
Oplev is disabled. I removed one of the steering mirrors because it was on the green beam path.
Since the beam waist after the Faraday had changed since the last time I measured it (maybe alignment changed a bit), I made a new mode matching calculation for green. I attached the results.
I'm going to align the beam into the Yarm.
RXA: JPG images deleted - replace with PDF please.
The PI pzt holders are back from the shop. They are numbered 1, 2 & 3 and machined to match.
Tapered black delrin opener is to gauge the gap if it is too small to fit pzt. This is to prevent holder to be opened too much.
Thin wall connector from McMCarr#55275K25 was tested in 150 mW, 1 mm beam size of 1064 nm overnight. It did not show any degradation.
Atm2, Enclosure viewport adaptor is shown in place of the viewport.
Soft gaskit - durumeter hardness 10A - McMCarr#9010K51 was added on the 10" od sufaces of conflat and viewport adaptor to insure being air tight.
The duct connector clamped with soft braided elastic " Velstrech" brand loop.
This entry is meant to be a sort of inventory check and a tentative plan-of-action for the installation of the PZT mounted mirrors and associated electronics on the Y-endtable.
High-Voltage Power Supply
Situation at rack 1Y4
This is an update on the situation as far as PZT installation is concerned. I measured the required cable (PZT driver board to PZT) lengths for the X and Y ends as well as the PSL table once again, with the help of a 3m long BNC cable, just to make sure we had the lengths right. The quoted cable lengths include a meter tolerance. The PZTs themselves have cable lengths of 1.5m, though I have assumed that this will be used on the tables themselves. The inventory status is as follows.
I also did a preliminary check on the driver boards, mainly to check for continuity. Some minor modifications have been made to this board from the schematic shown here (using jumper wires soldered on the top-side of the PCB). I will have to do a more comprehensive check to make sure the board as such is functioning as we expect it to. The plan for this is to first check the board without the high-voltage power supply (using an expansion card to hook it up to a eurocrate). Once it has been verified that the board is getting powered, I will connect the high-voltage supply and a test PZT to the board to do both a check of the board as well as a preliminary calibration of the PZTs.
To this end, I need something to track the spot position as I apply varying voltage to the PZT. QPDs are an option, the alternative being some PSDs I found. The problem with the latter is that the interfaces to the PSD (there are 3) all seem to be damaged (according to the labels on two of them). I tried connecting a PSD to the third interface (OT301 Precision Position Sensing Amplifier), and hooked it up to an oscilloscope. I then shone a laser pointer on the psd, and moved it around a little to see if the signals on the oscilloscope made sense. They didn't on this first try, though this may be because the sensing amplifier is not calibrated. I will try this again. If I can get one of the PSDs to work, mount it on a test optical table and calibrate it. The plan is then to use this PSD to track the position of the reflected beam off a mirror mounted on a PZT (temporarily, using double sided tape) that is driven by feeding small-amplitude signals to the driver board via a function generator.
The LEMO connector on the PZTs have the part number LEMO.FFS.00, while the male SMB connectors on the board have the part number PE4177 (Pasternack)
Plan of Action:
The wiring scheme has been modified a little, I am uploading an updated one here. In the earlier version, I had mistaken the monitor channels as points from which to log data, while they are really just for debugging. I have also revised the coaxial cable type used (RG316 as opposed to RG174) and the SMB connector (female rather than male).
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 did the following with the PZT Driver Board:
With an expansion card attached to the driver board, I used an Agilent E3620A power supply to verify that the 15V and 24V supplies were reaching the intended ICs. It turns out that the +24 V supply was only meant to power some sort of on-board high voltage supply which provided the 100V bias for the PZTs and the MJE15030s. This device does not exist on the board I am using, jumper wires have been hooked up to an SMA connector on the front panel that directly provides 100V from the KEPCO high voltage supply to the appropriate points on the circuit.
All the AD797s as well as the LT1125CS ICs on the board were receiving the required +15V.
The next step was to check the board with the high-voltage power supply connected.
The output from the power supply is drawn from the rear output terminal strip of the power supply via pins TB1-2 (-OUT) and TB1-7 (+OUT). I used a length of RG58 coaxial cable from the lab and crimped a BNC connector on one end, and stripped the other to attach it to the above pins.
There are several options that can be configured for the power supply. I have left it at the factory default: Local sensing (i.e. operating the power supply using the keypad on the front of it as opposed to remotely), grounding network connected (the outputs of the power supply are floating), slow mode, output isolated from ground.
I then hooked up a function generator in order to simulate a control signal from the DAC. The signal was applied to pin 2 of the jumpers marked JP1 through JP4 on the schematic, one at a time. The signal applied was a 0.2 Vpp, 0.1 Hz sine wave.
ETMY optical table top was grounded to the ETMY chamber through 1 Mohms this morning. I also strain releifed relieved a few cables that were pulling on components directly.
I measured the maximum output of the DAC at 1Y4 as well as its power spectrum. The results are as follows (plots below):
Therefore, the gain of the high-voltage amplification stage on the PZT driver boards do not need to be changed again, as the required output range of 0-100V from the DAC board was realised when the input voltage ranged from -10V to +10 V w.r.t ground. The AI board converts the differential input to a single ended output as required by the driver board.
I will now change some resistors/capacitors on the AI board such that the position of the notches can be moved from 16k and 32k to 64k and 128k.
Max. amplitude measurement
My previous measurement of the maximum output amplitude of the DAC was flawed as I made the measurement using a single channel of the oscilloscope, which meant that the negative pin of the DAC channel under test was driven to ground. I redid the measurement to avoid this problem. The set up this time was as follows:
The trace on the oscilloscope is shown below;
So with reference to ground, the DAC is capable of supplying voltages in the range [-10V 10V]. This next image shows all three traces: positive and negative pins of DAC w.r.t ground, and the difference between the two.
Power spectrum measurement
I used the SR785 to make the measurement. The set up was as follows:
Initially, I output no signal to the DAC, and obtained the following power spectrum. The peak at 65.554 kHz is marked.
I then re-did the measurement with a 200 Hz (left) and 2000 Hz(right), 1000 counts amplitude (I had to change the Ch1 input range on the SR785 from -18dBm to -6dBm) sine wave from channel 9 of the DAC, and obtained the following. The peaks at ~64 kHz are marked.
Now that this peak has been verified, I will work on switching out the appropriate resistors/capacitors on the AI board to move the notches from 16k and 32k to 64k and 128k.
We need the unit of the voltage power spectrum density to be V/sqrt(Hz).
Otherwise we don't understand anything / any number from the plot.