All suspentions are kicked up. Sus dampings and oplev servos turned off.
c1iscey and c1lsc are down. c1asc and c1iovme are up-down
The computers and RFM network are up working again. A boot fest was necessary.Then I restored all the parameters with burtgooey.
The mode cleaner alignment is in a bad state. The autolocker can't get it locked. I don't know what caused it to move so far from the good state that it was till this afternoon. I went tuning the periscope but the cavity alignment is so bad that it's taking more time than expected. I'll continue working on that tomorrow morning.
I now suspect that after the reboot the MC mirrors didn't really go back to their original place even if the MC sliders were on the same positions as before.
While Clara was working on her Wiener filtering and optimizing the locations of the accelerometers, she discovered that MC_L and MC_L_256 are totally flatlined. I looked at them, and it looks like they've been dead since ~9:30pm-ish on Sunday night. Bootfest-type activities shall commence shortly.
Under Alberto's tutalage, I rebooted the whole vme set (iovme, sosvme, susvme1, susvme2), and after that MC_L was all good again.
I added a temporary channel, to input 9 on the PEM ADCU. Beware the 30, 31, and 32 inputs. I tried 32 and it only gave noise.
There managed to be just enough 100 kOhm resistors to stuff all the "2" channels (VERT2, N/S2, E/W2) with the fancy low-noise resistors. The first six channels (VERT 1/2, NS 1/2, EW 1/2) are now completely done with the thin-film resistors, taking into account the changes that were made on the circuit diagram. I also replaced the C8 capacitor with the fancy Garrett ones and added capacitors on top of R4 and R13 (after painstakingly making sure that the capacitances are exactly the same for each pair) for the "2" channels. It looks like the capacitors on the "1" channels are the cheaper ones. I will compare the noise measurements later to see if there is any difference - if so, I can replace those as well (although, we're out of the 1 uF capacitors needed for C8).
Speaking of, we are now out of or very low on several types of the Garrett resistors/capacitors: 1 uF, 1kOhm, 100 Ohm, 14.0 Ohm, and 100 kOhm. I left the specifics on Steve's desk so that more can be ordered for the eventual time when the third set of channels needs to be restuffed.
I came into the 40m to sign things out briefly then swiftly return them, and the alarms were going off on op540m at 1am.
The cat and donkey? were making much noise.
I found the alignment biases for the PRM and the SRM in a funny state. It seemed like they had been "saved" in badly misaligned position, so the restore scripts on the IFO configure screen were not working. I've manually put them into a better alignment.
APC Smart-UPS (uninterruptible power supply) batteries RBC12 replaced at 1Y8 vacuum rack.
Their life span were 22 months.
Before heading back to the 40m to check on the computer situation, I thought I'd check the web screenshots page that Kakeru worked on, and it looks like none of the screens have been updated since June 1st. I don't know what the story is on that one, or how to fix it, but it'd be handy if it were fixed.
Apparently I broke this when I added op540m to the webstatus page. It's fixed now.
I've been trying for most of the week to get noise measurements on the output of the Guralp box as well as scross the AD640 chip. The measurements haven't really been making sense, and, being at a loss as to what else I should try, I decided to redo the resistors on the N/S 2 and E/W 2 channels. (I had been comparing the VERT1 and VERT2 channels, as VERT1 has been restuffed and VERT2 has not.) I don't need all three of the second set of channels to do more measurements, so it seemed like a good use of time.
The first thing I noticed was that the VERT2 channel was missing two resistors (R24 and R25). I probably should have noticed this sooner, as they are right by the output points I had been measuring across, but it didn't occur to me that anyone did anything to the VERT2 channel at all. So, probably the measurements on VERT2 are no good.
Note the existence of 100 kOhm resistors on the top channel, and none on the bottom channel (VERT2).
Then, while I was soldering in some 100 Ohm resistors, I happened to notice that the resistors I was using had a different number (1001) on them than the corresponding ones on the already redone channels (1003). I checked the resistance, and the ones on the already redone channels turned out to be 100 kOhm resistors, rather than 100 Ohms. So, I double checked the circuit diagram to make sure that I had read it correctly, and there were a number of resistors that had been relabeled as 100 Ohms and several relabeled as 100 kOhms. On the board, however, they were ALL 100 kOhms. Clearly, one of them is wrong, and I suspect that it is the circuitboard, but I don't know for sure.
The diagram clearly shows that R6 should be a 100k resistor, while R5 and R8 should be 100 Ohm resistors, but they are all the same (100k) on the board. I suspect this may have something to do with larger-than-expected noise measurements. But, it's possible the diagram is wrong, not the board. In any case, I didn't really know what to do, since I wasn't sure which was right, so I just replaced all the resistors I was sure about and removed the 100k and 100 Ohm resistors without replacing them with anything. Incidentally, the box of 100kOhm resistors seems to be missing, so I wouldn't have been able to finish those anyway.
It's railed. This is what halted locking progess on Monday night, as this channel is used for the offloadMCF script, which slowly feeds back a CARM signal to the ETMs to prevent the VCO from saturating.
Attached is a 5 day trend, which shows that the channel went dead a few days ago. All the channels shown are being collected from the same ICS110B (I think), but only some are dead. It looks like they went dead around the time of the "All computers down" from Sunday.
Attached are the channels being recorded from the ICS110B in 1Y2 (the IOO rack). Channels 12, 13, 16, 17, 22, 24, 25 appear to have gone dead after the computer problems on Sunday.
This has been fixed by one of the two most powerful & useful IFO debugging techniques: rebooting. I keyed the crate in 1Y2.
I made and tested a female-to-female TRS(audio)-RNC cable. It only has a single channel, so it won't work for stereo speakers or anything, but I should only need one speaker for testing the microphones. The tip of the plug is the signal, the sleeve is ground, and the ring is null.
The fb40m just went out of order with status indicator number 8
It recovered on its own five minutes later.
Backup script restarted, backup of trend frames and /cvs/cds is up-to-date.
Since lately the alignment of the input beam to the interferometer has changed, I went checking the alignment of the beam on the photodiodea. They were all fine except for pd9, that is AS DD 199. Here the DC is totally null. The beam seems to go right on the diode but the scope on the PD's DC output shows no power. This is really strange and bad.
After inspecting PD9 with the viewer and the cards, the beam looks like it is aligned to the photodiode althought there is no signal at the DC output of the photodetector. So I checked the spectrum for PD9_i and Q (see attachments) and it seems that those channels are actually seeing the beam. I'm going to check the alignemtn again and see the efefct on the spectra to make sure that the beam is really hitting the PD.
I aligned PD9. Here are the spectra confirming that.
Using FET probes, I was able to measure a transfer function that looks a little more like what I expected. There are only two peaks, but I think this can be explained by a short between the two capacitors (and two tunable capacitors) in the LC pairs, as shown (in red) in the circuit diagram attached. The measured transfer function (black), along with the simulated transfer functions with (red) and without (blue) the short are shown in the attached plot. The measured transfer function doesn't look exactly like the simulated transfer function with the short, but I think the difference can be explained by stray impedances.
Koji recommended that we use the optical setup pictured below. Although it uses fewer optics, I can't think of a way to test the phase camera using this configuration because any modulation of the wavefront with a lens or whatever would be automatically corrected for in the PLL so I think I'll have to stick with the old configuration.
I talked with Zach. So this is just a note for the others.
The setup I suggested was totally equivalent with the setup proposed in the entry http://22.214.171.124:8080/40m/1721, except that the PLL PD sees not only 29.501MHz, but also 1kHz and 59.001MHz. These additional beating are excluded by the PD and the PLL servo. In any case the beating at 1kHz is present at the camera. So if you play with the beamsplitter alignment you will see not only the perfect Gaussian picture, but also distorted picture which is resulted by mismatching of the two wave fronts. That's the fun part!
The point is that you can get an equivalent type of the test with fewer optics and fewer efforts. Particularly, I guess the setup would not be the final goal. So, these features would be nice for you.
Yet again, the DAQAWG flipped out for an unknowable reason. In order of restart activities listed on the Wiki, I keyed the crate and nothing really happened, then I hit the physical reset button and nothing happened, and then I did the 'telnet....vmeBusReset', and a couple minutes later, it was all good again.
Lately, I have been able to externally trigger the camera using a signal generator passing through the op-amp circuit that I built. The op-amp circuit stabilizes the jitter in the sine wave from the signal generator and rectifies the wave. I wrote the calculations into the code allowing me to find the phase and amplitude from the images I take. I still need to develop code that will plot these arrays of phase and amplitude.
The mysterious dark band at the top of the ccd images continues to defy explanation. However, I have found that it only appears for short exposure times even when the lens is completly covered. During the next couple of days, I will try to write a routine to correct for this structure in the dark field.
Koji recommended that we use the optical setup pictured below. This configuration would require fewer optics and we would have to rely on slight misalignments between the carrier and reference beams to test the effectiveness of the phase camera instead of a wavefront-deforming lens.
I've spent most of the last week working on finishing up the UCSD calculations, comparing it to the EUCLID design, and thinking about getting started with a prototype and modelling in MATLAB. Attached is something on EUCLID/UCSD sensors.
This week I've been working on testing the first version of the prototype circuit. Initially, I tested the circuit that I built last week, which had resistors in the place of the transformer. The magnitude and phase of the transfer function, as measured by the Agilent 4395A, are shown in the attached plot (first plot, MeasuredTransferFunction_R.jpg). The transfer function doesn't look like the simulated transfer function (second plot, BuiltCkt_ExpectedResponse.png), but I think I see the three peaks at least (although they're at the wrong frequencies). I spent some time trying to recreate the actual transfer function using LTSpice, and I think it's reasonable that the unexpected response could be created by extra inductance, resistance, capacitance and interaction between components.
When the transformer arrived yesterday, I replaced the resistors in the circuit with the transformer, and I have measured the following response (last plot, MeasuredTransferFunction.jpg). The gain is much lower than for the circuit with the resistors; however, I am still trying to track down loose connections, since the measured transfer function seems very sensitive to jiggled wires and connections.
Meanwhile, the parts for a flying-component prototype circuit have been ordered, and when they arrive, I'll build that to see if it works a little better.
So, I actually took these measurements last week, but I didn't get around to making nice plots and things until now. I figured the time while I wait for the spectrum analyzer to do its thing was a good time.
Having been unable to locate the SR785 and also unsure how to connect it to a computer speaker (and also unable to find a free one), I downloaded a demo of a function generator onto my computer and just used that. (Same thing I used to do the swept sine that created the frequency power response plots I posted last week.) I set the program to a number of different frequencies and had the other end of the cable hooked into the oscilloscope to see a) if I could pick out the frequency and b) see how the magnitude of the microphone output varied with the frequency.
The first set of measurements I took, I didn't realize that I could increase the output power of the function generator. Because the generated sound at the default setting was relatively quiet, the oscilloscope traces were pretty chaotic, so I usually froze the trace so that I could look at it better. I ended up with a lot of weird jumps in the magnitude, but I later realized that there was a lot of beating going on at some frequencies, and the amplitude changes were probably much more drastic for the -20 dB sounds than the 6 dB sounds, since it was closer in amplitude to the surrounding noises. So, I've included that data set in my plots for the sake of completeness, but I'm pretty sure that it is useless.
Once I realized I could increase the power output for the signal generator, I took a set of data with and without the voltage divider at 6 dB. There was a cluster of frequencies that showed significant beating around 1700-3000 Hz in the data WITH the voltage divider, but I did not see any clear beating in the data WITHOUT. In the plots, I simply plotted up the highest and lowest amplitudes I measured for the frequencies with significant beating, since it was obviously hard to tell what the amplitude would have been without any background noise. In the w/o volt. div. set, although I didn't see any obvious beat patterns, the measured amplitudes did jump slightly at the frequencies that showed beats with the voltage divider. So, perhaps I was just not seeing them, but they influenced my amplitude measurements? I'm not sure if it would be possible for the voltage divider itself to cause beat frequencies.
(Note: the amplitudes measured were from zero to peak, as the oscilloscope I was using wouldn't show a big enough vertical range to easily measure the peak-to-peak voltage difference.)
I've attached two plots of my measurements. One has a regular x-scale and includes all the measurements. The second has a logarithmic x-scale and omits the 20 Hz points. I had some troubles being able to pick out the 20 Hz signal on the oscilloscope... I don't know if my computer speakers just don't work well at that frequency or what, but either way, those points seemed highly suspect, and omitting them from the log plot allowed me to spread things out more.
One thing I'm not sure about is the 3000 Hz point. It was one of the ones with a beat frequency (~130 Hz), and the amplitudes were pretty low. The corresponding point from the non-voltage-divider data set is also low. So, I'm not sure what's happening there.
The one thing that I do think is quite clear is that the 1000 Hz drop-off in power when the microphone is connected to the ADC has nothing to do with the voltage divider. Beat issues aside, the shapes are very similar (pay no attention to the absolute scale... obviously, the voltage responses with and without the voltage divider were very different, and I just scaled them to fit in the same plot).
Update: Jenne pointed out that I was not absolutely clear about the voltage scale in my plots. The GREEN and BLUE points are on a mV scale, and the RED points are on a 10mV scale. I should probably redo the plots in Matlab in eventuality, since Excel is hard to use if you want to do anything that is not extremely basic with your plots, but this was my solution for the time being. So, the fact that the RED points, which are the data taken WITHOUT the voltage divider, are lower than the GREEN ones does not in any way indicate that I measured lower voltages when the voltage divider was not used.
Also, a to do list:
- Many of the beat frequencies I picked out were veeeeery slow, indicating that something is going at a frequency that is very close to the arbitrary frequencies I chose to sample, which is a little strange. That, combined with the fact that I saw clear beats with the voltage divider but not without leads me to believe that it may be worth investigating the frequency response of the voltage divider itself.
- Redo the measurements near the anomalous 3000 Hz point with a higher density of sampled frequencies to try to see what the heck is going on there.
Alex and Steve,
SunFire x4600 ( not MEGATRON 2 , it is fb40m2 ) and JetStor ( 16 x 1 TB drives ) were installed on side rails at the bottom of 1Y6
We cleaned up the fibres and cabling in 1Y7 also
Today, I moved the router from on top of the PSL into the control room in order to perform dark field tests on the GC650 (which I also moved). The GC750 along with the lens that was on it and the mount it was on has been lent to Ricardo's lab for the time being. I successfully triggered the GC650 externally and I also characterized the average electronic noise. For exposure times less than 1 microsecond, the average noise contribution appears to be a constant 15 on a 12-bit scale.
Today Alex came over, performed his magic rituals on the DAQAWG computer and fixed it. Now it's up and running again.
I asked him what he did, but he's not sure of what fixed it. He couldn't remember exactly but he said that he poked around, did something somewhere somehow, maybe he tinkered with tpman and eventually the computer went up again.
Now everything is fine.
I popped by the 40m, and was dismayed to find that all of the front end computers are red (only framebuilder, DAQcontroler, PEMdcu, and c1susvmw1 are green....all the rest are RED).
I keyed the crates, and did the telnet.....startup.cmd business on them, and on c1asc I also pushed the little reset button on the physical computer and tried the telnet....startup.cmd stuff again. Utter failure.
I have to pick someone up from the airport, but I'll be back in an hour or two to see what more I can do.
I think the problem was caused by a failure of the RFM network: the RFM MEDM screen showed frozen values even when I was power recycling any of the FE computers. So I tried the following things:
After Alberto's bootfest which was more successful than mine, I tried powercycling the AWG crate one more time. No success. Just as Alberto had gotten, I got the DAQ screen's AWG lights to flash green, then go back to red. At Alberto's suggestion, I also gave the physical reset button another try. Another round of flash-green-back-red ensued.
When I was in a few hours ago while everything was hosed, all the other computer's 'lights' on the DAQ screen were solid red, but the two AWG lights were flashing between green and red, even though I was power cycling the other computers, not touching the AWG at the time. Those are the lights which are now solid red, except for a quick flash of green right after a reboot.
I poked around in the history of the curren and old elogs, and haven't found anything referring to this crazy blinking between good and bad-ness for the AWG computers. I don't know if this happens when the tpman goes funky (which is referred to a lot in the annals of the elog in the same entries as the AWG needing rebooting) and no one mentions it, or if this is a new problem. Alberto and I have decided to get Alex/someone involved in this, because we've exhausted our ideas.
I have increased the temperature setpoint in the office area by ~0.75 deg F. Figure attached. Also a few days ago I increased the setpoint of the AC in the control room. Looks like the Laser is able to handle the changes in office area temperature so far, but lets see how it fares over the weekend.
Bonnie has been strung up on bungees in the PSL so that her position/orientation can be adjusted however we like. She is now hanging pretty low over the table, rather than being attached to the hanging equipment shelf thing. Butch Cassidy has been hung over the AS table.
Moving Bonnie increased the coherence for the PMC_ERR_F signal, but not the MC_L. Butch Cassidy doesn't have much coherence with either.
I noticed that the coherence would drop off very sharply just after 10 kHz - there would be no further spikes or anything of the sort. I used my computer to play a swept sine wave (sweeping from 20Hz to 10kHz) next to Butch Cassidy to see if the same drop-off occurred in the microphone signal itself. Sure enough, the power spectrum showed a sharp drop around 10kHz. Thinking that the issue was that the voltage dividers had too high impedance, I remade one of them with two 280 Ohm and one 10 Ohm resistor, but that didn't make any difference. So, I'm not sure what's happening exactly. I didn't redo the other voltage divider, so Bonnie is currently not operating.
In her position overlooking whichever table it is that is next to the PSL, Bonnie drummed up some decent coherence with the PSL-PMC_ERR channel, but not so much with the MC_L. I moved her into the PSL itself, and now there is rather good coherence with the PMC_ERR channel, but still not so great for MC_L.
Bonnie's new home in the PSL.
Today I tuned the periscope on the PSL table to align the beam to the Mode Cleaner. With the Wave Front Sensor control off, I minimized the reflection from the MC and maximized the transmission. While doing that I also checked that the transmitted beam after the MC didn't lose the alignment with the interferometer's main Faraday isolator.
In this way, I've got a reflection, as read from the MC_REFLPD_MC, of about 0.6. Then I centered the WFS on the AS table. After that the WFS alignment control brought the reflection to 0.25 and a nice centered bull-eye spot showed on the monitor.
The beam scan (which has been living in the bridge subbasement for a bit now) is in a state of imperfection.
I noticed that:
I took some pictures to try and illuminate the situation - The inverted images are included to make it easier to see the flecks (?) in the slits
I am not sure how to figure out if any bit of the scan is/has been fried.
Pending further investigation, enjoy large error bars in your scan measurements!
PICTURES OF BOTH SLITS ON THE BEAMSCAN HEAD: