Using the equation for thermal resistance
Rthermal = L/(k*A)
where k is the thermal conductivity of a material, L is the length, and A is the surface area through which the heat passes, I could find the thermal resistance of the copper and stainless steel on the reference cavity. To reduce temperature gradients across the vacuum chamber, the thermal resistance of the copper must be the same or less than that of the stainless steel. Since the copper is directly on top of the stainless steel, the length and width will be the same for both, just the thickness will be different (for ease of calculation, I assumed flat, rectangular strips of the metal). Assuming we wish to have a thermal resistance of the copper n times less than that of the stainless steel, we have
RCu = RSS/n
L/(kCu*w*tCu) = L/(kSS*w*tSS*n)
tCu/tSS = n*kSS/kCu
We know that kSS = 401 W/m*K and KCu = 16 W/m*K, so
tCu/tSS = 0.0399*n
By using the drawings for the short reference cavity vacuum chamber (the only one I could find drawings for online) I found a thickness of the walls of 0.12 in or 0.3048 cm. So for the same thermal resistance in both metals, the copper must be 0.0122 cm thick and for a thermal resistance 10 times less, it must be 0.122 cm thick. So we will have to keep wrapping the copper on the vacuum chamber!
The vent has been finished successfully in this morning.
The vent was finished successfully this morning.
This past week I have worked on the following:
1. Setting up the infrastructure to do noise analysis: We added a temporary channel on the DAQ to connect to the PD 55 which we are using to take the power measurement. Before that, I connected the PD55 to an oscilloscope and recorded the power.
The power at PD55 as measured using the oscilloscope = 600 µV.
Then I tried to calibrate the channel by sending up a signal from the function generator and measuring up the offset.. However, the channels seems noisy enough, especially due to electronics noise as suggested by the measurements and FFT calculation.
2. I worked on trying to sync the data acquisition of the PD and the CAM. After sometime spent on fiddling with the software method such as taking images at stamped time and then lining them up with the daq timestamps, I found a hardware method as suggested by Aidan. It was putting up a shutter (Uniblitz shutter and driver VMMD1) in the setup. I synced the shutter with the camera for which I had to tear apart the previously made trigger box and add a sync output from the camera (took a while as I also had to make a new cable).
3. I worked (still working) on making a differential amplifier to blow up the signal from the PD.
We are moving towards a first test of getting Kiwamu's green locking signals into the new front end at the new X end, as well as sending signal out to the green laser temperature control.
Towards that end, we borrowed the router which we were using as a firewall for megatron. At the moment, megatron is not connected to the network. The router (a linksys N wire router), was moved to the new X end, and setup to act as a firewall for the c1iscex machine.
At this point, we need to figure which channels of the DAC correspond to which outputs of the anti-imaging board (D000186) and coil driver outputs. Ideally, we'd like to simply take a spare output from that board and bring it to the laser temperature control. The watchdogs will be disabled when testing to avoid any unfortunate mis-sent signals to the coils. It looks like it should be something like channels 6,7,8 are free, although I'm not positive if thats the correct mapping or if there's a n*8 + 6,7,8 mapping.
The ADC should be much easier to determine, since we only have a single 16 channel set coming from the lemo breakout box. Once we've determined channels, we should be all set to do a test with the green system.
This past week, we levitated our small cylindrical magnet (with the flag made from heat shrink). Though the levitated magnet didn't appear very jittery to the eye, we looked at the PD current on the scope and could see oscillations that corresponded to the flag hitting the sides of the OSEM. The oscillations were more pronounced as we gently hit/vibrated the lab bench, and by pounding on the bench Rana knocked the levitated magnet completely out of the setup. So, we're currently working on building a new, stabler mount. The biggest challenge here is fixing the OSEM in place, but we're experimenting with different optics pieces to see which is the most stable for our purposes. Jenne taught us how to make through holes using the drill press so we can add slats of aluminum to adjust the height of the OSEM mount. We also plan to fix some heavy plates to the bottom of our system to decrease its vibration frequency.
We also calculated the transfer function of our circuit, which seems to match the measured frequency response to within a small factor. We're playing with Rana's Simulink models and are currently modeling our own system to determine what gains we would expect to use and get a better understanding of our circuit.
Once our system is successfully mounted stably, we plan to experimentally observe the effects of changing the gain and integrator by looking at time series measurements of the PD current, as well as using the spectrum analyzer to compare the frequency response of our system at different gain settings.
Summary of this week's activities:
7/14: Analytical calculation of Viton spring constant; updated Viton values in models; experimental confirmation of COMSOL eigenfrequencies (single stack layer)
7/15: Extensions to 2-, 3-, and 4-layer stack legs. Eigenfrequency characterizations performed for each level. Meshing issues with 4-layer stack prevented completion.
7/19: Debugged the 4-layer stack. Turned out to be a boundary condition issue because of non-sequential work-plane definitions. Successful characterization of single-leg eigenfrequencies.
7/20: Prototype three-legged stack completed, but dimensions are incorrect. Read Sievers paper for details of triple-legged stack. Sorted through many stack design binders in efforts to distinguish IOC/OOC, BSC/ITMX/ITMY, MC1/MC3, and MC2 dimensions.
7/21: Researched frequency domain analysis testing in COMSOL. Attempting to first find transfer function of a single-layer stack --> currently running into some run-time errors that will need some more debugging in the afternoon.
The vent is still going on. At this moment the pressure inside of the chambers is about 630 Torr.
Koji and I have replaced the 2nd instrument grade compressed air cylinder by the 3rd cylinder around 9 pm.
So far the vent speed has been nicely kept at about 1 Torr / min.
Yesterday I installed teh QPD on the table behind MC2, and observed teh signal on it.
The MC_leak is directed to it by a steering mirror.
I used the A2L_MC2 script to minimise teh pitch and yaw gains, and estimated teh spot position on teh MC2 using that.
This spot position was aligned to the center of teh QPD.
In the night while before taking measurements, I decided to turn off the Wavefront Sensor Servos, but just after that, the MC alignment went very bad, and I could not align it in the next 2 hours.
For some reason, the MC was really mad the whole day yesterday, and was getting misaligned again and again, even when the WFS feedback was on.
The table also had another IR laser in it, which I and Koji switched off.
I will continue measuring once we pump down again.
For now, I am analysing teh QPD circuit Transfer Function.
Some clarification is warranted regarding the different shapes of stacks. Corrections are appreciated:
1) The single-leg stack that I just completed should function as a working model for the IO, OO, and MC1/3. Rana commented, however, that the current dimensions are slightly off for MC1/3 (which makes sense since I could only find drawings for the IOC). If anyone knows the whereabouts of similar drawings for MC1/3, I'd much appreciate it.
2) A triple-leg stack can model the BS, ITMX, and ITMY chambers. I don't have exact dimensions for these, but I can make decent approximations from to-scale stack drawings. I'll probably work on a model for this style next, since at least I have some information regarding this version.
3) The MC2 chamber has its own stack model, about which I haven't found any drawings in the binders. I can't start on MC2C at all until I find such drawings.
After the crane training, Bob attached speakers to the ceiling right next to the projector, for use with presentations.
We plotted the transfer functions for the maglev control circuit and compared them with the plots from the spectrum
analyzer. We were stuck for sometime because
1) we had wrongly entered the value of one of the resistors which was off by a factor of 2000.
2) The plots were not done in right units. So we couldn't figure out differences quite well.
The two plots are shown below. We are still off by a factor of 3 which we'll figure out soon.
I moseyed into the control room this morning, to find ITMX and ITMY both with their watchdogs tripped. ITMY (new convention) wouldn't damp. Koji discovered that there was a sign flip in 2 of the sensors. A set of reboots of c1susvme1&2 fixed the problem.
A side note: For the ETMs, the OSEM sensor readouts are gigantic (~20,000), whereas for the similar channels on all other optics, the readouts are on the order of 1. After some looking around, it seems that this is just the way things have been (for at least 100 days), and the filters in the SUSPOS and other SUS filter banks have a high pass filter to take care of this. It's weird, but it seems to be the way it is, and the ETMs damp, so it's all good.
The PSL shutter was closed. The beam path blocked two places. High voltage power supplies to IOO and OMC PZT were checked to be off. Oplevs are off.
The south arm green cavity was misaligned yesterday
We would like to keep the vent speed at 1 torr / min. I'm venting with N2 now up to 25 PSI. We have 3 cylinder of instrument grade air inside the lab. Additional supply will arrive later. It can be as late as 1pm
Since we now have a good measurement of the phase noise of the Rb clock Marconi locked to the Rb clock, I wanted to use that to check out the old DAQ system:
I used Megan's phase noise setup - Marconi #2 is putting out 11000013 Hz at 13 dBm into the ZP-3MH mixer. Marconi #1 is putting out 3 dBm at 11000000 Hz into the RF input.
The output goes through a 50 Ohm load and then a Mini-Circuits BNC LP filter (either 2 or 5 MHz). Then an SR560 set for low noise, G = 5, AC coupling, 1-pole LP @ 1 kHz.
This SR560 output goes into the channel C1:IOO-MC_DRUM1 (which is sampled at 16384 Hz with ICS-110B after the usual Sander Liu AA chassis containing the INA134s).
Expanding on the single-layer model, I added the second, third, and fourth layers to the stack in COMSOL. Eigenfrequency analysis run times increased exponentially as the model multiplied in complexity. The following images document the some of the important eigenfrequencies:
First Eigenmode: y-translational, 3.34 Hz:
Second Eigenmode: x-translational, 3.39 Hz:
Third Eigenmode: z-rotational, 3.88 Hz:
Sixth Eigenmode: z-translational, 8.55 Hz:
As expected, the eigenfrequencies are generally lower, but still in the same range, as the single-layer model, because of greater mass but constant weight-per-spring distribution.
1) Extend a single stack to the full stack system, which consists of three stacks like this. Perform similar eigenmode analysis.
2) Analyze the mirror suspension system and incorporate a similar pendulum on the top plate.
3) Make transfer function measurements between seismic and mirror motions.
Friday night myself and Koji measured the Transfer function of the QPD circuit at MC2 side using a chopper . Following was our procedure :
We connected some wires at the input and output of teh filter circuit to one of the segment of teh QPD. - seg 2.
A laser light was shined on to the QPD, it was pulsed using a chopper. The frequency of rotation of teh chopper was varied.
These wires were then fed to the spectum analyser , and a transfer funstion was observed, It was nearly a low pass filter
The chopper frequency was then made variable by giving the chopper a signal from teh spectrum analyser. This signal just swiped a large range of the rpm of the chopper.
Now the input signal looked like a sine wave of varying frequency. the transfer functino looked like a perfect LPF, with a small SNR.
Attaching the plot of the TF in the next e-log (this one is on windows and cant access /cvs/cds)
We connected some wires at the input and output of the filter circuit to one of the segment of teh QPD. - seg 1.
A laser light was shined on to the QPD, it was pulsed using a chopper. The frequency of rotation of the chopper was varied.
The chopper frequency was then made variable by giving the chopper a signal from the spectrum analyser. This signal just swiped a large range of the rpm of the chopper.
Now the input signal looked like a sine wave of varying frequency. the transfer function looked like a perfect LPF, with a small SNR.
Attaching the plot of the TF in the next e-log (this one is on windows and can't access /cvs/cds)
The timing slave in the IO chassis on the new X end was not working with symptoms of no front "OK" green light, no "PPS" light, 3.3V testpoint not working and ERROR testpoint bouncing between 5-6V.
We took out the timing slave from the X end IO chassis put in to the new Y end IO chassis .
It worked perfectly there. We took the working one from Y end put in the X end IO chassis.
We slowly added cables. First we added power , it worked fine and we saw green "OK" light. Then we added 1PPS signal by a fiber and it also worked.
We turned everything off and then we added 40pin IPC cable from the chassis and infiniband cable from the computer.
When we turned ON it we didn't see the green light.
This means something in the computer configuration might be wrong not in the timing card, we now are trying to make contact with Alex.
We are comparing the setup of the C1SCX machine and the working C1ISCEX machine.
To make the beam on the MC trans camera bigger, I removed the lens + ND filter that was in that path.
The camera was getting the transmission through a BS1-33 (33% reflector). The reflection went to the TRANS QPD. I changed
the R=33% into an HR mirror (Y1-45P) so now the camera has a nice beam. The QPD was now saturating so I put a ND06 into that path
so now the TRANS_SUM is ~4.5-5 V when the MC is aligned.
The MC was also misaligned and failing to lock all weekend (why??) so I aligned the MC mirrors to get it to acquire again. Since we want to
collect MC seismic data, please make sure the MC is locked and running after finishing with your various MC or PSL work (this means YOU).
From the trend, it seems that the Reference Cavity's temperature servo is working fine with the new copper foil. I was unable to find the insulating foam anywhere, but that's OK. We'll just get Frank to make us a new insulation with his special yellow stuff.
The copper foil that Steve got is just the right thickness for making it easy to form around the vacuum can, but we just have to have the patience to wrap ~5-10 more layers on there. We also have to get a new heater jacket; this one barely fits around the outside of the copper wrap. The one we have now seems to have a good heating wire pattern, but I don't know where we can buy these.
I also turned the HEPA's Variac back down to the nominal value of 20. Please remember to turn it back up to 100 before working on the PSL.
Rana and I
1) took the temperature sensors off the reference cavity;
2) wrapped copper foil around the cavity (during which I learned it is REALLY easy to cut hands with the foil);
3) wrapped electrical tape around the power terminals of the temperature sensors (color-coded, too! Red for the out of loop sensor, Blue for the first one, Brown for the second, Gray for the third, and Violet for the fourth. Yes, we went with an alphabetical coding system, excluding the out of loop sensor);
4) re-wrapped the thermal blanket heater;
5) covered the ends of the cavities with copper, ensuring that the beam can enter and exit;
6) took pretty pictures for your enjoyment!
We will see if this helps the temperature stabilization of the reference cavity.
The end of the reference cavity, with a lovely square around the beam.
The entire, well-wrapped reference cavity!
Today I noticed that the FE SYNC counters of c1susvme1/2 on the RFM network screen were stuck at 16384. I tried to reboot the machines to fix the problem but it didn't work.
The BS watchdog tripped off when I did that, because I had forgotten to disable it. I had to wait for a few minutes before it settled down again.
Later I also re-locked the mode cleaner. But before I could do it, Rana had to reduce the MC_L offset for me.
After talking with Jenne, I realized the ADC card in the c1ass machine was currently going unused. As we are short an ADC card, a possible solution is to press that card into service. Unfortunately, its currently on a PMC to PCI adapter, rather than PMC to PCIe adapter. The two options I have are to try to find a different adapter board (I was handed 3 for RFM cards, so its possible there's another spare over in downs - unfortunately I missed Jay when I went over at 2:30 to check). The other option is put it directly into a computer, the only option being megatron, as the other machines don't have full length PCI slot.
I'm still waiting to hear back from Alex (who is in Germany for the next 10 days) whether I can connect both in the computer as well as with the IO chassis.
So to that end, I briefly turned off the c1ass machine, and pulled the card. I then turned it back on, restarted all the code as per the wiki instructions, and had Jenne go over how it looked with me, to make sure everything was ok.
There is something odd with some of the channels reading 1e20 from the RFM network. I believe this is related to those particular channels not being refreshed by their source (which is other suspension front end machines), so its just sitting at a default until the channel value actually changes.
We finished setting up the new X end front end machine (still temporarily called c1scx), and attached it to its IO chassis. We're preparing for a test tomorrow, where we redirect the Limo breakout box to the new front end and IO chassis, so Kiwamu can test getting some green locking channels into his controls model.
We strung a pair of blue fibers from the timing master to the new X end (and labeled them), so we have a timing signal for the IO chassis. I also labeled the orange fiber Alex had repurposed from the RFM to timing for the new Y end when I noticed he had not actually labelled it at the timing master.
I tuned the gain of WFS to 0 last night at about 3am.
I turned it back on now.
[Jenne & Kyung-ha]
We suspended the mirror to one of the main frame with the ECD backplane we finished before. The hard task was to find the right balance for the mirror so that 1) it won't be tilted and 2) it'll be in the right position for the ECD backplanes so that the magnets attached to the mirror holder would be in the very center of each ECD holes. We used optical lever laser (red He/Ne) to check the balance of the mirror. We tried to use the jig for the mirror holder clamps but because of the size difference, we couldn't use it at all. (Since the magnets are very heavy, we thought the wire being not perfectly centered might work better. However, the jig dimension was way too different that the wire ended up in the middle of one of the holes.) Since there was no other clever way to attach the wire in the right position, we just tried to be as center/accurate as possible. After attaching wire to that mirror holder clamps, we hanged it to the frame. Again, we couldn't find any other accurate way to find the center so we held the wire and tried to adjust the mirror height as accurate as possible so that it can be in the right position in respect to ECD backplane and not be tilted at the same time. However, when we hanged the mirror, it was still tilted.. So we adjusted the mirror tilt using the mirror holder clamps. Since the holes on the clamps were ellipse shapes, we could adjust the position of the clamps a little bit. When we adjust the clamps, we started to tighten the screws when the mirror is NOT in the perfect position since the tightening up part changes the mirror angle anyways. Luckily, when we tightened up the last screw, the mirror was in the perfect position! After that, we poked the mirror several times to make sure that it comes back to the same place.
Amazingly, we could finish this whole hanging/adjusting process in about 30 mins! :D (Jan said it's because of his amazing moral support. :P Maybe he'll be there to support us everytime we work on the mirrors?)
After last night's challenge (or inspiration), we levitated our magnet this morning. Since the nice Olympus camera is not currently in the 40m, we had to use my less stellar camera, but despite the poor video quality you can still see the magnet returning to its stable equilibrium position. Once we recover the better camera, we will post new videos. Also, we haven't yet figured out how to put videos in line in the elog entry, so here are the youtube links:
We adjusted the gain on coil 1 so that the resistance from the pots was 57.1k (maximum gain of 101.2,).
currents from power supply, pre-levitation: 0.08 A and 0.34 A
post levitation: 0.08 A and 0.11 A
note: we're not sure why changing the gain on coil 3 changes the current through the power supply, so we'd like to investigate that next.
You guys must work harder.
As you can see, there was not much (if any) worsening of the laser frequency fluctuation from removing the RefCav insulation. The plots below are zooomed in:
I have used the same peak-to-peak scale so that its easy to compare the fluctuations before (LEFT) and after (RIGHT).
As you can clearly see, the laser frequency moves just as much now (the SLOW_DC) as it did before when it had the insulation. Only now the apparent (i.e. fake) RC temperature fluctuations are much larger. So this sensor is fairly useless as configured.
Sometimes I like to plot the spectrum of MC_F. Its a good diagnosis of whether something is wrong.
The red trace is noisier than the blue reference. What is the cause of this?
This is the machine which will be the new x end front end machine. Its IP is 192.168.113.86.
We changed the root and controls passwords to the usual. We have modified the controls user group to be 1001, by using "usermod -u 1001 controls" (we had to use the non-rtl kernel to get that command to work).
We changed /etc/fstab to point to /cvs/cds on Linux rather than some downs machine. We added a link to /cvs/cds/rtcds in the local /opt directory.
We modified the /etc/rc.d/rc.local file to no longer run /opt/open-mx/sbin/omx_init start, /cvs/cds/geo/target/fb/mx_stream -d scipe12:0 om1, and /cvs/cds/geo/target/fb/mx_stream -d scipe12:0 -e2 -r2 om2. We modified the /usr/bin/setup_shmem.rtl to run only c1x00 c1scx and c1spx.
I also commented out a line0 "/bin/rm -f /rtl*"
Tell me whether it is correct or not. Otherwise I won't be able to sleep tonight.
According to these results, these would be the proposed adjustements to the cavity lengths:
dl(PRC) = -0.0266 m; dl(SRC) = 0.612 m
Sorry. I was in a rush to go to the LIGO "all hands" meetings when I posted that elog entry, that I forgot a zero in the SRC length value. The correct values are:
dl(PRC) = -0.0266 m; dl(SRC) = 0.0612 m
The cavity absolute lengths are then:
L(PRC) = 0.5/2/f1*c - 0.0266 = 6.7466 m
L(SRC) = c/f2 + 0.0612 = 5.4798 m
where c is the speed of light; f1 = 11065399 Hz; f2 = 55326995 Hz
According to these results, these would be the proposed adjustements to the cavity lengths:
dl(PRC) = -0.0266 m; dl(SRC) = 0.612 m
Lately I've been trying to calculate the corrections to the recycling cavity lengths that would compensate for the phase that the sidebands will pick up from the arms in the upgraded interferometer.
To do that calculation , I tried two quite different ways, although equivalent in principle. They both use the optickle model of the 40m, but the calculation is made differently.
In the first way, I looked directly at the phases of the field: phase of [input field] / [reflected field], phase of [input field at PRM] / [transmitted field at SRM].
In the second way I looked at the demodulation phases of the LSC signals.
The first way is much simpler, especially from a computational point of view. It is the first I tried several weeks ago, but then I had abandoned because back then I thought it wasn't the correct way.
Anyway, both ways gave me the same results for the PRC length.
For the SRC length, the first way has given me a clear outcome. On the other hand, the second way has produced a less clear result.
According to these results, these would be the proposed adjustements to the cavity lengths:
dl(PRC) = -0.0266 m; dl(SRC) = 0.0612 m
I) 1st Way
a) case of arms ideal length (33.86 m)
b) case arm length = 38.40 m
II) 2nd Way
a) case of arms ideal length (33.86 m)
I modified the C1ADCU_PEM.ini file in /cvs/cds/caltech/chans/daq/ (after making a backup), and added a temporary channel called C1:PEM-TEMP_9, the 9 corresponding to the labeled 9 channel on the front of the BNC breakout in the 1Y7 rack. The chnnum it was set to is 15008 (it was commented out and called C1:PEM-PETER_FE). I also set the data rate to 2048.
I then did telnet fb40m 8087, and shutdown, and also hit the blue reconfig button on the DAQ status screen for the C0DCU1 machine. The framebuilder came back up. I confirmed the temporary channel, as well as the Guralp channels were still working from C0DCU1.
We have strung a cable in the cable trays from the SP table to the 1Y7 rack, which has been labeled as "Phasecam PD". This will be used to record the output of an additional photodiode.
I borrowed the Olympus and forgot to leave a note - I should have it for at most a day. dmassey@ligo if you need it urgently
I experimentally determined the spring constant of a single Vitol spring in order to obtain a rough estimate for the natural frequency of single-stack oscillation.
The procedure basically involved stacking metal bars of known mass onto the Vitol and using a caliper to measure deviations from the equilibrium length.
The plot below shows that, for small compressions, the response is linear to an R-squared of 0.98.
The experimental spring constant came out to be about 270 lb/ft, or 3900 N/m.
Previous documents have listed that the top stack takes on a load of approximately 43 kg. per individual spring. A bit of calculation yields an experimental resonant frequency of 9.5 Hz.
Compared with the theoretical COMSOL first harmonic of about 7.5 Hz, there is a reasonable amount of error. Of course, I used this calculation as a simple ballpark estimate: errors from misplacement onto the Viton were minimized through use of a level, but were still inevitable on the mm scale. Since the two methods yield answers with the same order of magnitude, we are ready to move forward and build the remaining layers of the stack.
My previous eigenfrequency analysis was incorrect by two orders of magnitude due to the misuse of Young's Modulus information for Viton. After editing this parameter (as documented on 7/14 19:00), the eigenmodes became much more reasonable. I also discovered the Deformation option under the Surface Plotting Options, which makes the eigenmodes of the single stack much more apparant.
Attached are pictures of the first four eigenmodes:
First Eigenmode: y-translational, 7.49 Hz
Second Eigenmode: x-translational, 7.55 Hz
Third Eigenmode: z-rotational, 8.63 Hz
Fourth Eigenmode: z-translational, 18.26 Hz
Viton flouroelastomers have somewhat variable material properties. The following parameters are being used for eigenfrequency analysis.
Young's Modulus: 72,500-87,000 psi (cite: http://www.row-inc.com/pfa.html) *Accurate for PFAs
Poisson's Ratio: 0.48-0.50 (cite: http://www.engineeringtoolbox.com/poissons-ratio-d_1224.html) *Accurate for rubber
Density: 1800 kg/m^3 (cite: http://physics.nist.gov/cgi-bin/Star/compos.pl?matno=275)
The Young's Modulus for PFA turned out to be orders of magnitude greater than for Viton. The revised values produced much more accurate results:
Young's Modulus for Viton-75: 1950 psi or 6.6 MPa
(Courtesy Row, Inc. and Steve Vass)
This website contains other details: http://www.row-inc.com/viton.html
We made an attempt at cleaning up the phase camera setup electronics.
We have moved a portion of the electronics onto the SP table (specifically the mixer, splitters, amplifiers, and associated power). We put away a large number of cables which were unneeded, both BNC and power cables. The Innolight Mephisto power supply and one signal generator are still behind 1Y2 on top of a non-functioning VME crate. The second VME crate was put along the south arm where two other VME crates already were. We placed a fair number of BNC cables and power cords back on their cable racks or approriate storage space, so the rats nests of cables has been reduced.
We moved one power strip from plugging in beyind 1Y1, to the far side of the SP table (closer to the 1Y3 rack), and also found and plugged in another power strip (also on the far side of the SP table) and placed this underneath the SP table to be able to power the signal generator and Innolight Mephisto laser (its not plugged in currently, but we'd like to do so next week).
Joe got on the phone with Alex, and Alex's magic Alex intuition told him to ask about the RFM switch. The C0DAQ_CTRL's overload light was orange. Alex suggested hitting the reset button on that RFM switch, which we did. That fixed everything -> c0dcu1 came back, as did the frame builder. Rana had pointed out earlier that we could have brought back all of the other front ends, and enabled the damping of the optics even though the FB was still down. It's okay to leave the front ends & watchdogs on, and just reboot the FB, AWG, and DAQ_CTRL computers if that is necessary.
Anyhow, once the FB was back online, we got around to bringing back all of the front ends (as usual, except for the ones which are unplugged because they're in the middle of being upgraded). Everything is back online now.
After all of this craziness, all of the Guralp channels are working happily again. It is still unknown why they starting being digital zero, but they're back again. Maybe I should have rebooted the frame builder in addition to c0dcu1 last night?
This is regards to zero signal being reported by the channels C1:PEM-SEIS_GUR1_X, C1:PEM-SEIS_GUR1_Y, and C1:PEM-SEIS_GUR1_Z.
I briefly swapped Guralp 1 EW and Guralp 2 EW to confirm to myself that it was not on the gurlap end (although the fact that its digital zero is highly indicative a digital realm problem). I then unplugged the 17-32, and then 1-16 channel connections to the 110B. I saw floating noise on the GUR2 channels, but still digital zero on the GUR1 channels, which means its not the BNC break out box.
There was a spare 110B, unconnected in the crate, so to do a quick test of the 110B, I turned off the crate and swapped the 110Bs, after copying the switch configuration of the first 110B to the second one. The original 110B was labeled ADC 1, while the second 110B was labeled ADC 0. The switches were identical except for the ones closest to the Dsub connectors on the front. All those switches in that set were to the right, when looking down at the switches and the Dsub connectors pointing towards yourself.
Unfortunately, the c0duc1 never seemed to come up with the new 110B (ADC 0). So we put the original 110B back. And turned the crate back on.
The fb then didn't seem to come back quite right. We tried rebooting fb40m it, but its still red with status 1. c0daqctrl is green, but c0dcu1 is red, although I'm not positive if thats due to fb40m being in a strange state. Jenne tried a telnet in to port 8087 and shutdown, but that didn't seem to help. At this point, we're going to contact Alex when he gets in around 12:30.
Summary of this Week's Activities:
Wed. 7/7: COMSOL Busbar tutorials; began stack design; began base; Viton rubber research
Thurs. 7/8: Completed Viton rubber research; updated materials; finished designing the base layer
Fri. 7/9: Research model coupling papers; extensive eLog entry about base design and troubleshooting
Sun. 7/11: Played around with Busbar to find first eigenfrequency; continued crashing COMSOL
Mon. 7/12: Intrusions in COMSOL eLog tutorial entry; research eigenfrequency analysis; successfully got first eigenmode of rectangular bar
Tues. 7/13: Updated Poisson ratio of Viton and subsequently succeeded in running eigenfrequency tests on base stack layer. Systematic Perturbation Tests were documented in the most recent elog entry. Discussed results with Rana and decided this didn't make sense. Analytical study required.
Wed. 7/14: Went over to machine shop to experimentally extrapolate spring constant of Viton. Calculations to be done in the afternoon.
Summary of this week's work
Wednesday - Aligned the mode cleaner with Koji, and then measured the beam characteristics at MC2 end. Koji then taught me how to read the WFS signals
Thursday - wrote a script to measure the signals and calculated the coefficients relating mirror movement and DC signals of WFS. To know the possibility of the control, found SVD of the coeff matrix, and condition number.
Friday - Set up the measurement of QPD linear response using a laser outside the cavity. Took data.
Monday - did the calculations and plotting for the above experiment. Then played around with the MEDM screens , and also tried to see what happens to the Power Spectrum of WFS signals by changing the coefficients in teh matrix. (failed)
Tuesday - played around with WFS, tried seeing what it does when switched on at different points, and also what it does when I disturb the system while WFS has kept it locked.
This week I was mainly interested in investigating the noise source at the phase camera. So having this issue in mind, my activities are the following:
1. I worked on producing multiple beat signal (1Hz and 5Hz). Elog entry.
2. I altered the setup so that instead of triggering the camera from the signal generator, we are now triggering it from the beat signal from the reference beam and sideband.
3. I made the nice little aluminium table for all the amplifiers, mixer and splitters to sit at one place instead of floating around.
4. I talked with Aidan and Joe and verified my calculation and extended it to further investigation of the noise source in the setup.
Plan for the upcoming week:
1. Measure and calibrate the camera w.r.t the power incident on it.
2. Investigate the noise source.
Razib and I were attempting to get the output of a photodiode (PD55A in this case) recorded, so that we could independently measure the slow (~1-10 Hz) fluctuations of the light incident on the camera. This would then allow us to subtract those fluctuations out, letting us get at the camera noise in the case with signal present (as opposed to just a dark noise measurement when we look at the noise with no signal present).
Originally I was thinking of using one empty patch panel BNCs used for PEM channels down by the 1Y7 rack and go through a 110B, although Alberto pointed out he had recently removed some monitoring equipment, which watched the amplitude modulation at various frequencies of the RF distribution (i.e. 33 MHz, etc). This equipment output a DC voltage proportional to the amplitude of the RF signals. The associated channel names were C1:IOO-RFAMPD_33MHZ, C1:IOO-RFAMPD_33MHZ_CAL, C1:IOO-RFAMPD_133MHZ, etc. These are slow channels, so I presume they enter in via the slow computers, probably via pentek (I didn't check that, although in hindsight I probably should have taken the time to find exactly where they enter the system). The connections them selves were a set of BNCs on the south side, half way up the 1Y2 rack.
We simply chose one, the 33 MHz channel in this case, and connected. At around this time, the MC did become unlocked, although it looked like it was due to the MC2 watchdog tripping. The initial theory was we had bumped the Mode Cleaner while looking around for some BNC cables, although from what Rana had to do last night, it probably was the connection. We were able to restore the watchdog and confirm that the optic started to settle down again. Unfortunately, I had to leave about 5 minutes later, and didn't do as thorough an investigation as was warranted.
Before I left, I disconnected the PD55, so the 33 MHz channel wasn't physically connected to anything!!! Only one end of the wire was connected to the rack while the other was free...
So it wasn't the PD connection that is responsible for MC tripping at the later time...
We correctly connected our circuit to power source to verify that it was functional and that our LED in the shadow sensor turned on. It did, but we also noticed a funky signal from the LED driver. We continued to attempt 1x1 levitation, but determined that the temporary flag we were using out of convenience (a long, thin cylindrical magnet) was weakly attracted to residually magnetized OSEM components. We then switched to an aluminum screw as our flag.
We resoldered and applied heat shrink to the wires connecting our coil to the BNC terminal, since they were falling apart.
We sat down with Rana and removed circuit components in the LED drive part by part to determine what was tripping up the circuit. We determined a rogue capacitor to be at fault and removed it from the circuit.
We used a spectrum analyzer to measure the frequency response of our circuit (see details in last elog). We are currently making a Simulink block diagram so we can check the stability of our setup, but are temporarily set back because our plotted calculation of the transfer function clearly doesn't match the measured one.
Yesterday we hooked up the Quadrant Maglev control to the power supply to test the components in the Input/Output part of the circuit.
The output from the buffer was an unexpected high noise signal which was caused by some circuit components.
The following is a story of how it was done.
To test the components of input/output, we measured the output across TP_PD3(Test Point -Photo Diode 3).
We got a high noise signal with a frequency of several kHz.
We tested the values of various electronic components. The resistances R5 and R6 did not measure as mentioned(each had a value of 50 K in the schematic). The value of R6 was 10 K and we replaced R5 with a 10 K resistor. We still got the noise signal at 5.760 kHz with a Pk-Pk voltage of 2.6 V. The resistors in R-LED measured 1.5 K instead of the marked 2.2 K.
We had three suspects in hand:
BUF634P : The data sheet for the BUF634P instructed a short across the 1-4 terminals in the presence of capacitive load. We followed this to overcome the effect(if any) of the extra-long BNC cables which we were using. The oscilloscope still waved 'Hi!' at a few kHz. We removed the buffer and also the feedback resistor R42 from the circuit, what we were testing boiled down to measuring the output of the Sallen-Key filter. The output still contained the funny yet properly periodic signal at a few kHz.
C24: Removing C24 did not do any good.
C23: As a final step C23 was removed. And ... We got a stable DC at 9.86 V(almost stable DC with a low noise at a few MHz). C24 and the buffer were replaced and output seemed fine. The output was a high frequency sine wave which was riding on a DC of 9.96 V.
We rechecked if the LED was on and the infrared viewer gave a positive signal.
We went ahead obtaining the transfer function of the feedback control for which we used a spectrum analyzer.
The input for feedback system is a photo current whereas the spectrum analyzer tests the circuit with a voltage impulse. Hence the voltage input from the spectrum analyzer needs to be converted into current of suitable amplitude(few microamps) for testing the spectrum analyzer. Similarly the output which is a coil current needs to be changed to a voltage output through a load for feeding into the channel of the spectrum analyzer. We used a suitable resistance box with BNC receiving ends to do this. We obtained a plot for the transfer function which is shown below.
- Check the calculated transfer functions with the plot of the spectrum analyzer
- Model the entire(OSEM, magnet, actuators etc.) system in Simulink and calculate the overall transfer function
- Stable levitation of the 1X1 system
Sanjit discovered that the Gur1 channels are all digital 0. We determined that this began on July8, 04:00 UTC (~9pm on the 7th?).
It's digital zero, so we suspect a software thing. Just to check, we put a sine wave in, and didn't see anything. Gur2 seems totally fine, and the sine wave input showed up nicely on dataviewer. What's going on? Sabotage to prevent this paper from getting done? Dmass trying to get his paper done before me???
Investigations are ongoing.... Joe claims it's not his fault, since his shenanigans near the PEM rack were on days before, and days after this, but not on the 7th.
I just rebooted c0dcu1, which didn't help anything. Joe said he'd try to give me a hand tomorrow.