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.
I measured FSS's open loop transfer function.
For FSS servo schematic, see D040105-B.
4395A's source out is connected to Test point 2 on the patch panel.
Test Point 2 is enabled by FSS medm screen.
"A" channel is connected to In1, on the patch panel.
"R" channel is connected to In2, on the patch panel.
the plot shows signal from A/R.
Note that the magnitude has not been corrected for the impedance match yet.
So the real UGF will be different from the plot.
network analyzer mode
frequency span 1k - 10MHz
Intermediate frequency bandwidth 100Hz
Attenuator: 0 for both channels
Source out power: -30 dBm
sweep log frequency
medm screen setup
Common gain -4.8 dB
Fast Gain 16 dB
After whatever Joe/Alberto did this afternoon, the MC was not locking. Koji and I removed several of the cables in the side of the rack where they
were apparently working (I say apparently because there's no elog).
MC is now locking but the autolocker did not work at first - op340m was unable to access any channels from c1iool0. After several minutes, it mysteriously
started working - the startup.cmd yields errors seen on the terminal. I attach the screen dump/.
For yesterday - July 12th.
Yesterday, I tried understanding the MEDM and the Dataviewer screens for the WFS.
I then also decided to play around with the sensing matrix put into the WFS control system and see what happens.
I changed the sensing matrix to completely random values, and for some of the very bad values, it even lost lock :P (i wanted that to happen)
Then I put in some values near to what it already had, and saw things again.
I also put in the matrix values that I had obtained from my DC calculations, which after Rana's explanation, I understand was silly.
Later I put back the original values, but the MC lock didnot come back to what it was earlier. Probably my changing the values took it out of the linear region. THE MATRIX NOW HAS ITS OLD VALUES.
I was observing the POwer Spectrum of teh WFS signals after changing the matrix values, but it turned out to be a flop, because I had not removed the mean while measuring them. I will do that again today, if we obtain the lock again (we suddenly lost MC lock badly some 20 minutes ago).
Via reconfiguration of Viton parameters (previously posted), I managed to debug the COMSOL run time errors and null pointer exceptions. Listed are the resultant eigenfrequencies obtained through structural analysis testing. For all tests, the bottom of the Viton springs are constrained from motion, and all other parts are free to oscillate. Notice that color variations signify displacement from the equilibrium position. Also note that different initial conditions produce different eigenmodes:
No initial displacement:
0.01 m x-displacement:
0.01 m y-displacement:
0.01 m z-displacement:
Clearly, the plate has its first harmonic between 210-215 Hz, which is much greater than seismic noises (which never exceed the 10-Hz range). This suggests a highly attenuating transfer function. Since the remaining three plates have been designed to resonate similarly, it is likely that the entire stack system will also function very well.
1) Extend the eigenfrequency analysis to obtain a transfer function for the single-plate system
2) Expand the CAD model to include all four stack layers, and perhaps a base
It seems like you might inherit an offset by using step (3) b/c of the temperature gradient between the crystal and the sensing point. Depending on how large this gradient is you could increase the linear coupling from temperature to intensity noise from zero to a significant number. Phase noise should not be effected.
SInce these things (ovens) are so low time constant, shouldn't we
The optimum temperature for the doubling crystal on the PSL table was found to be 36.8 deg.
I scanned the temperature of the crystal from 44 deg to 29 deg, in order to find the optimum temperature where the frequency doubled power is maximized.
The method I performed is essentially the same as that Koji did before (see this entry).
(1) First of all, I enabled the PID control on the temperature controller TC200 and set the temperature to 44 deg.
(2) After it got 44 deg, I disabled the PID control.
(3) Due to the passive cooling of the oven, the temperature gradually and slowly decreased. So it automatically scans the temperature down to the room temperature.
(4) I recorded the power readout of the power meter: New Port 840 together with the temperature readout of TC200. The power meter was surely configured for 532 nm.
The measured data are shown in the attachment.
The peak was found at T=36.8 deg where the power readout of 532 nm was 605 uW.
Compared with Koji's past data (see this entry), there are no big side lobes in this data. I am not sure about the reason, but the side lobes are not critical for our operation of the green locking.
(to be done)
Adjustment of the PID parameters
I have just removed an other 400 cc of water from the chiller. I have been doing this since the HTEMP started fluctuating.
The Neslab bath temp is 20.7C, control room temp 71F