ID |
Date |
Author |
Type |
Category |
Subject |
3270
|
Thu Jul 22 18:18:54 2010 |
Alberto | Update | PSL | Problem Solved |
Quote: |
Quote: |
It looks like something wrong happened around the PSL front end. One of the PSL channel, C1:PSL-PMC_LOCALC, got crazy.
We found it by the donkey alarm 10 minutes ago.
The attached picture is a screen shot of the PMC medm screen.
The value of C1:PSL-PMC_LOCALC ( middle left on the picture ) shows wired characters. It returns "nan" when we do ezcaread.
Joe went to the rack and powered off / on the crate, but it still remains the same. It might be an analog issue (?)
|
The problem seems to be a software one.
In any case, Kiwamu and I looked at the at the PMC crystal board and demod board, in search of a possible bad connection. We found a weak connection of the RG cable going into the PD input of the demod board. The cable was bent and almost broken.
I replaced the SMA connector of the cable with a new one that I soldered in situ. Then I made sure that the connection was good and didn't have any short due to the soldering.
|
[Alberto, Koji]
By looking at the reference pictures of the rack in the wiki, it turned out that the Sorensen which provides the 10V to the 1Y1 rack was on halt (red light on). It had been like that since 1.30pm today. It might have probably got disabled by a short somewhere or inadvertently by someone working nearby it.
Turning it off and on reset it. The crazy LO calibrated amplitude on the PMC screen got fixed.
Then it was again possible to lock PMC and FSS.
We also had to burtrestore the PSL computer becasue of the several reboots done on it today. |
440
|
Wed Apr 23 22:39:54 2008 |
Andrey | DAQ | Computer Scripts / Programs | Problem with "get_data" and slow PEM channels |
It turns out that I cannot read minute trends for the slow weather channels for more than 1000 seconds back (roughly more than 15 minutes ago) using "get_data" script.
For comparison, I tried MC1 slow channels, and similar problem did not arise there. Probably, something is wrong with the memory of slow weather channels. At the same time, I can see minute-trends in Dataviewer as long ago as I want.
In response to
>>get_data('C1: PEM-weather_outsideTemp', 'minute', gps('now') - 3690, 3600);
I get the error message:
"Warning: Missong C1: PEM-weather_outsideTemp M data at 893045156". |
261
|
Thu Jan 24 22:10:49 2008 |
Andrey | Configuration | Computer Scripts / Programs | Problem with channels - help of Rana, Robert or Steve is needed |
I definitely spoiled something (changes some settings) by chaotically clicking those blue buttons (see my previous entry # 260).
Unfortunately, I cannot use standard library of functions for reading from channels from mDV directory.
Although I see the curve of a noise in the Dataviewer from the channel "Ch1:SUS_ETMX_POS", when I try to read data from the channel using the program "get_data" from MDV directory, I get the error message
"Warning: No data available for [numbers representing "gps_start_time" and "gps_end_time"].
In new_readframedata at 136
In new_fetch_shourov at 71
In get_data at 98"
I checked, both gps-times are in the past from now, so as far I understand, nothing is recorded into the channels.
Of course, I added two hours ago to the directory "mDV", that is I used addpath(pwd) in that directory.
And I also cannot run the program that I used on Tuesday evening which takes data from "C1:SUS_ITMX_POS" (no data from that channel), which worked perfectly on Tuesday.
I again apologize for clicking the wrong blue button (see my explanation in my previous message #260). I ask someone who knows how to return normal working of channels (normal interaction of computer and channel memory) to do that.
Before that I cannot take data. I do not know how to restore the initial settings which existed before I started adding the channel to Dataviewer.
Andrey. |
1040
|
Fri Oct 10 13:57:33 2008 |
Alberto | Omnistructure | Computers | Problems in locking the X arm |
This morning for some reason that I didn't clearly understand I could not lock the Xarm. The Y arm was not a problem and the Restore and Align script worked fine.
Looking at the LSC medm screen something strange was happening on the ETMX output. Even if the Input switch for c1:LSC-ETMX_INMON was open, there still was some random output going into c1:LSC-ETMX_INMON, and it was not a residual of the restor script running. Probably something bad happened this monring when we rebooted all the FE computers for the RFM network crash that we had last night.
Restarting the LSC computer didn't solve the problem so I decided to reboot the scipe25 computer, corresponding to c1dcuepics, that controls the LSC channels.
Somehow rebooting that machine erased all the parameters on almost all medm screens. In particular the mode cleaner mirrors got a kick and took a while to stop. I then burtrestored all the medm screen parameters to yesterday Thursday October 9 at 16:00. After that everything came back to normal. I had to re-lock the PMC and the MC.
Burtrestoring c1dcuepics.snap required to edit the .snap file because of a bug in burtrestore for that computer wich adds an extra return before the final quote symbol in the file. That bug should be fixed sometime.
The rebooting apparently fixed the problem with ETMX on the LSC screen. The strange output is not present anymore and I was able to easily lock the X arm. I then run the Align and the Restore full IFO scripts. |
2491
|
Sat Jan 9 09:47:03 2010 |
Alberto | Update | LSC | Problems trying to lock the arms |
This morning I've been having problems in trying to lock the X arm.
The X arm's filter FM6 in the LSC screen starts blinking as it was halfloaded. Then the transmitted power drops from 1 to ~0.5 and eventually the arm loses lock.
To me it looked like a computer related issue. So I decide to reboot C1ISCEX by powercycling it.
That doesn't seem to have solved the problem. The X arm can get locked but TRX slowly moves between 0.2 and 1. |
2492
|
Sat Jan 9 11:07:30 2010 |
Alberto | Update | LSC | Problems trying to lock the arms |
Quote: |
This morning I've been having problems in trying to lock the X arm.
The X arm's filter FM6 in the LSC screen starts blinking as it was halfloaded. Then the transmitted power drops from 1 to ~0.5 and eventually the arm loses lock.
To me it looked like a computer related issue. So I decide to reboot C1ISCEX by powercycling it.
That doesn't seem to have solved the problem. The X arm can get locked but TRX slowly moves between 0.2 and 1.
|
The X arm is now locked with TRX stable at ~1.
I think earlier on today I was having problems with running the alignment scripts from op540. Now I'm controlling the IFO from Rosalba and I can easily and stably lock all degrees of freedom.
I needed the X arm to be locked to align the auxiliary beam of the AbsL experiment to the IFO. To further stabilize TRX I increased the loop gain from 1 to 1.5.
Now the auxiliary beam is well aligned to the IFO and the beat is going through the PRC. I'm finally ready to scan the recycling cavity.
I also changed the gain of the PRC loop from -0.1 to -0.5. |
536
|
Tue Jun 17 22:00:53 2008 |
John | HowTo | PSL | Problems turning MZ servo on/off |
We were unable to toggle the MZ servo on/off (Blank/Normal) from MEDM. Pushing on the Xycom board and cables changed the fault from constant to intermittent. At least one lock loss has been caused by a MZ glitch. |
9160
|
Wed Sep 25 19:34:51 2013 |
rana | Update | SUS | Problems with ETMY Optical Lever |
I went down to investigate the issue with the extra noise that I found in the ETMY optical lever yesterday. There were several problems with the optical layout down there - I'm not sure if I remember them all now.
- Beam reflected from OL QPD not dumped.
- OL QPD set normal to the steering mirror so that the back reflection goes into the vacuum chamber.
- HeNe laser mount only dogged with 2 dogs. Needs 3. Looks like some said "Aw, that's not goin' nowhere. Let's just leave that there pard!"
- First lens downstream of the laser had 2 screws and washers, but neither was even finger tight! They were loose by more than 1 full turn.
- Second lens was clipping. Beam was so far off center that this lens was being used to steer the beam by a few inches on the QPD.
- Extra reflections from ingoing beam (I don't know which surfaces) randomly landing on green & red optics.
- Lenses for the HeNe mode matching are coated for 1064 nm. HeNe is 633 nm, so these lenses must be replaced to reduce the reflections.
The main noise issue, however, appears to be not a layout issue at all. Instead its that the laser intensity noise has gone through the roof. See attached spectra of the quadrants (this is the way to diagnose this issue).
I'll ask Steve to either heal this laser or swap it out tomorrow. After that's resolved we'll need another round of layout fixing. I've done a couple of hours today, but if we want a less useless and noisy servo we'll have to do better.
NOTE: by looking at the OL quadrants, I've found a noisy laser, but this still doesn't explain the excess noise in the ETMX. That was the one that has a noisier error signal, not ETMY. By the coherence in the DTT, you can see that the ETMY OL is correctly subtracting and normalizing out the intensity noise of the laser. Seems like the ETMX electronics might be the culprit down there. |
9165
|
Thu Sep 26 11:00:51 2013 |
Steve | Update | SUS | Problems with ETMY Optical Lever |
We are out of JDSU-Uniphase 1103P heads. I'm ordering some right now. I'm planning to make some corrections on Rana's list tomorrow morning at ETMY. |
9166
|
Thu Sep 26 21:55:08 2013 |
rana | Update | SUS | Problems with ETMY Optical Lever |
Not so fast! We need to plan ahead of time so that we don't have to repeat this ETMY layout another dozen times. Please don't make any changes yet to the OL layout.
Its not enough to change the optics if we don't retune the loop. Please do buy a couple of JDSU (and then we need to measure their intensity noise as you did before) and the 633 nm optics for the mode matching and then we can plan about the layout. |
12427
|
Sun Aug 21 17:21:22 2016 |
Praful | Update | Electronics | Problems with PCB Circuit |
For the past week, I've been trying to make a soldered amplifier circuit to use in a prototype box, However, I've been running into this same issue. The circuit, pictured below, works fine on a solderless breadboard.

simple_amp.png
When I amplify a sine wave, I get a clean looking result at the output on the solderless breadboard:

However, on my soldered circuit, if I turn up the negative voltage supply from the power supply past about -12.5V (the target is -15V), I get a strange signal that Gautam suggested looks like some kind of discharging.
At -12.3 V (soldered breadboard):

At -15.0 V (soldered breadboard):

The signal is much noisier. Zooming in on this second signal, this pattern appears:


This pattern is also showing up even when there is no input from the function generator and the circuit is just given a voltage supply of +/- 15V:

I have tried switching out both the positive and negative voltage regulators, the opamp, and remaking and resoldering the entire circuit but I'm still getting the same signal, which is absent from the solderless circuit. This output was produced with a function generator, so I have also ruled out the microphone as a source of this extra noise. The voltage dependence of this problem made me think it was the voltage regulator, but I've switched out the voltage regulator multiple times and it's still showing up. I'm not sure why this signal appears only as the negative voltage supply is increased- there is no problem with increasing the positive input voltage. Please let me know if you have any ideas as to what component or issue could be causing this. |
56
|
Thu Nov 1 20:03:00 2007 |
Andrey Rodionov | Summary | Photos | Procedure "Drop and Drag" in pictures |
|
15462
|
Thu Jul 9 16:02:33 2020 |
Jon | HowTo | CDS | Procedure for setting up BHD front-ends |
Here is the procedure for setting up the three new BHD front-ends (c1bhd, c1sus2, c1ioo - replacement). This plan is based on technical advice from Rolf Bork and Keith Thorne.
The overall topology for each machine is shown here. As all our existing front-ends use (obsolete) Dolphin PCIe Gen1 cards for IPC, we have elected to re-use Dolphin Gen1 cards removed from the sites. Different PCIe generations of Dolphin cards cannot be mixed, so the only alternative would be to upgrade every 40m machine. However the drivers for these Gen1 Dolphin cards were last updated in 2016. Consequently, they do not support the latest Linux kernel (4.x) which forces us to install a near-obsolete OS for compatibility (Debian 8).
Hardware
-
-
IPC cards: Dolphin DXH510-A0 (PCIe x4 Gen1) [LLO will provide; I've asked Keith Thorne to ship them]
-
-
-
Software
- OS: Debian 8.11 (Linux kernel 3.16)
- IPC card driver: Dolphin DX 4.4.5 [works only with Linux kernel 2.6 to 3.x]
- I/O card driver: None required, per the manual
Install Procedure
- Follow Keith Thorne's procedure for setting up Debian 8 front-ends
- Apply the real-time kernel patches developed for Debian 9, but modified for kernel 3.16 [these are UNTESTED against Debian 8; Keith thinks they may work, but they weren't discovered until after the Debian 9 upgrade]
- Install the PCIe expansion cards and Dolphin DX driver (driver installation procedure)
|
5464
|
Mon Sep 19 16:44:16 2011 |
Keiko | HowTo | LSC | Procedure for the demodulation board check |
Here I note the procedure for the demodulation board orthogonality check for the future reference.
1. prepare two function generators and make sure I an Q demodulation signals go to the data acquisition system.
2. sync the two generators
3. drive the function generator at the modulation frequency and connect to the LO input on the demod board
4. drive the other function generator at the modulation frequency + 50Hz the RF in
5. run "orthogonality.py" from a control computer scripts/demphase directory. It returns the amplitude and phase information for I and Q signals. If necessary, compensate the amplitude and phase by the command that "orthogonality.py" returns.
If you want to check in the frequency domain (optional):
1. 2. 3 are the same as above.
4. drive the function generator at the LO frequency + sweep the frequency, for example from 1Hz to 1kHz, 50ms sweep time. You can do it by the function generator carrier frequency sweep option.
5. While sweeping the LO frequency, run "orthogonality.py"
6. The resulting plot from "orthogonality.py" will show the transfer function from the RF to demodulated signal. The data is saved in "dataout.txt" in the same directory. |
9573
|
Fri Jan 24 12:44:25 2014 |
Gabriele | HowTo | LSC | Procedure to measure PRC length |
Here is how to measure the PRC length with a set of distance measurements in the optical setup.
We need to take distance measurements between reference points on each mirror suspension. For the large ones (SOS) that are used for BS, PRM and ITMs, the reference points are the corners of the second rectangular base: not the one directly in contact with the optical bench (since the chamfers make difficult to define a clear corner), but the rectangular one just above it. For the small suspensions (TT) the points are directly the corners of the base plates.
From the mechanical drawings of the two kind of suspensions I got the distances between the mirror centers and the reference corners. The mirror is not centered in the base, so it is a good idea to cross check if the numbers are correct with some measurements on the dummy suspensions.
I assumed the dimensions of the mirrors, as well as the beam incidence angles are known and we don't need to measure them again. Small errors in the angles should have small impact on the results.
I wrote a MATLAB script that takes as input the measured distances and produce the optical path lengths. The script also produce a drawing of the setup as reconstructed, showing the measurement points, the mirrors, the reference base plates, and the beam path. Here is an example output, that can be used to understand which are the five distances to be measured. I used dummy measured distances to produce it.

In red the beam path in vacuum and in magenta the beam path in the substrate. The mirrors are the blue rectangles inside the reference bases which are in black. The thick lines are the HR faces. The green points are the measurement points and the green lines the distances to be measured. The names on the measurement lines are those used in the MATLAB script.
The MATLAB scripts are attached to this elog. The main file is survey_v2.m, which contains all the parameters and the measured values. Update it with the real numbers and run it to get the results, including the graphic output. The other files are auxiliary functions to create the graphics. I checked many times the code and the computations, but I can't be sure that there are no errors, since there's no way to check if the output is correct... The plot is produced in a way which is somehow independent from the computations, so if it makes sense this gives at least a self consistency test. |
9574
|
Fri Jan 24 13:10:12 2014 |
Jamie | HowTo | LSC | Procedure to measure PRC length |
Quote: |
I wrote a MATLAB script that takes as input the measured distances and produce the optical path lengths. The script also produce a drawing of the setup as reconstructed, showing the measurement points, the mirrors, the reference base plates, and the beam path. Here is an example output, that can be used to understand which are the five distances to be measured. I used dummy measured distances to produce it.

|
This path does not look correct to me. Maybe it's because this is supposed to represent "optical path lengths" as opposed to actual physical location of optics, but I think locations should be checked. For instance, PRM looks like it's floating in mid-air between the BS and ITMX chambers, and PR2 is not located behind ITMX. Actually, come to think of it, it might just be that ITMX (or the ITMs in general) is in the wrong place?
Here is a similar diagram I produced when building a Finesse model of the 40m, based on the CAD drawing that Manasa is maintaining:

|
9575
|
Sat Jan 25 21:09:16 2014 |
gabriele | HowTo | LSC | Procedure to measure PRC length |
I know the drawing is wrong. I put random distances, not realistic ones, and I did not try to get something close to reality. Once we put the measured distances, the drawing should (hopefully) be correct. |
825
|
Mon Aug 11 15:07:49 2008 |
josephb | Configuration | Computers | Procyon aka fb40m switched to new switch |
I've connected Procyon to the Prosafe 24 port switch with a new, labeled Cat6 cable. Quick tests with dataviewer shows that its working. |
15802
|
Wed Feb 10 21:14:03 2021 |
gautam | Update | Electronics | Production version of the HV coil driver tested |
Summary:
I did what I consider to be a comprehensive set of tests on the production version of the high voltage coil driver circuit. I think the performance is now satisfactory and the circuit is ready for the production build. Barring objections from anyone, I will ask Chub to place an order for components to stuff the 4 necessary units + 1 spare on Friday, 12 Feb (so that people have a full day to comment). A big thanks to Chub and the folks at JLCPCB for dealing with my incessant order requests and patiently supporting this build and letting me turn this around in 10 days - hopefully this is the end of this particular saga.
Schematic is here. All references to component designations are for v4 of the schematic.
Important design changes:
- All I/O to this board will be via D9 connectors. This will allow bypassing the high voltage stage in future suspensions while retaining the same cable config in the suspension drive, if that is desired. Some re-arrangement of the grouping of coils was also done for consistency with the planned upgrade.
- Differential receiving for the input signal from the Acromag. The nominal quad opamp is LT1125 but if we find noise issues (which I didn't), the OP497 has compatible PCB footprint.
- Added input protection dual diode D6 to protect the PA95 as recommended in the datasheet. This should protect the IC if (for example) the HV line isn't plugged in but the Acromag input is non-zero.
- Increased the feedback resistance from 30kohms to 12kohms. R16 through R21 are now 20k, while the old design had 5k. The purpose is to reduce the current demand in the feedback path, hopefully this opens up the number of DCPS we can use. To keep the overall gain of 31, the resistor R15 was upped from 1kohms to 4kohms.
- Feedback capacitance reduced from 15 uF to 3 uF. This was largely for space saving / ease of layout on the PCB. The resulting corner frequency is increased slightly from 0.35 Hz to 0.45 Hz but this doesn't have any imapct on the performance of the circuit at frequencies of interest (1/2/pi/R/C had R=30k, C=15uF, now R=120k, C=3uF).
- Added an R-C-R network at the output of the PA95, before the fast actuation signal is summed and sent to the OSEM coil.
- This is probably the most important change, noise-performance wise.
- The purpose of the network is to passively filter out the excess noise we saw at ~100 Hz (the corner from the 4kohm resistor + 3uF cap is at ~13 Hz, so factor of 10 filtering at 100 Hz, which was deemed sufficient, see earlier elogs in the thread).
- The Johnson noise contribution of the 20 kohm resistor is slightly higher than the original design which had a 25 kohm series resistor (but no R-C-R passive filter at the output of the PA95). But once again, this was deemed to have negligible effect on the performance at frequencies of interest to us.
- The total current driving capability of the circuit is almost unchanged since the 20kohm + 4kohm nearly equals the old 25kohm resistance.
- Made the Vmon paths for monitoring the HV output of the PA95 differential sending, seems like a good practise to follow for all new designs.
- Added on-board bypass capacitors (2 x 10uF WIMA film caps) for cleaning up the HV supply noise.
Tests:
A series of tests were done. Note that only 1 channel was stuffed (I am out of PA95s), and the HP power supplies borrowed from Rich were used for the HV rails. For the +/-18V, a regular bench-top unit was used.
- Low voltage stage tests
- TF of the differential receiving stage was measured and the overall unity gain and corner at 24kHz were verified, see Attachment #1.
- With the input of the circuit grounded, I measured the noise of the circuit at various points (see legends on Attachment #2). I didn't bother to do a detailed verification against a SPICE model as the levels seemed roughly what is expected.
- Overall noise performance with HV stage enabled
- For a range of drive currents, generated by applying the appropriate voltage using an Acromag XT1541 DAC module to the J1 connector, I measured the voltage on the circuit side of the 20 kohm resistor (by clipping onto the resistor leg. Note that the path to ground for the current was provided by connecting a 20 ohm resistor between pins 1 and 6 on J3a, and then grounding pin 6.
- Results are shown in Attachment #3.
- For the drive currents at the edge of the range of operation, there is a small excess relative to lower drive currents. My best hypothesis for why this is happening is that the HV rail is too close to the requested output voltage (the HP units are rated for 320V, which is borderline if we want 300V at the output of the PA95). In any case, the R-C-R passive filter means that above ~60 Hz, there is excellent agreement between model and measurement.
- Time domain tests
- Used a function generator. to drive a 50 mHz, 3Vpp sine wave to the "Bias Input" (=J1), and monitored (i) pickoff of drive signal, (ii) High voltage output at the circuit side of the 20kohm resistor, and (iii) the Vmon output (=pins 1/6 on J4), all on a 100 MHz Tektronix scope.
- Results shown in Attachment #4. Once again, I see no red flags.
- While I had the unit hooked up to the scope, I also checked the time domain signal with the scope set to 100 ns/div time base. I saw no evidence of any oscillatory features, either when no input signal was applied, or when a DC signal was provided (in which case the scope was set to AC coupling). 👍
- Checked that the protection diodes at various locations in the circuit work.
- Checked the pin-mapping on all 6 D9 connectors is consistent with the top level diagram in the schematic.
PCB remarks:
As I was stuffing the board, I noticed a few improvements that can be made. Just noting these here for documentation purposes - these changes are mostly aesthetic and I personally see no need to order another set of PCBs.
- In some places, the silkscreen designators don't have the correct "orientation" relative to the component they are designating. I didn't find any serious ambiguity in terms of being misled to stuff the wrong component onto the wrong pads, but in the spirit of doing a professional job...
- The current limiting resistors on the +/-430V LEDs (R37/R38) have footprints for leaded components rather than SMT (which is what the +/-15V LEDs have).
- R45 and R46, the current limiting resistors for the rear panel power indicator LEDs, have 0805 footprint rather than 1206.
- When I drew up the PCB, R23, the 4kohm resistor in the R-C-R network, was set up as a 1W resistor. Let's say there can be 15 mA flowing through this resistor - the power dissipated is 15e-3 ^2 * 4e3 is 0.9W, which is uncomfortably close to the limit. For all the tests above, I used a 3W resistor, and didn't find any serious noise issues. The drilled holes are a little tight for this higher power rated resistor, but I don't think this is a showstopper.
Communications with Apex:
I've been talking to support at Apex, and pointed out that I couldn't match the SPICE model performance even for a simple non-inverting amplifier with the PA95. The feedback I got from them was that
- They don't optimize the SPICE models for input noise and so it was a nice coincidence that model and measurement are somewhat close (but not exactly).
- They recommend the PA194, which is actually advertised as "low-noise". The PA95 is apparently not a "low-noise" part, with its 2uVrms input noise.
Whiel the PA194 is compatible with our voltage and current requirements for this application, it is ~3x the cost, and seems like the R-C-R output filter allows us to realize the goal of 1pA/rtHz, so I'm inclined to stick with the PA95.
Production assembly:
I'd prefer to get as much of the board stuffed by Screaming Circuits as possible. It took me ~3 hours to stuff 1 channel + the power supply parts, standoffs etc. So I estimate it'll take me ~6 hours to stuff the entire board. So not the end of the world if we have to do it in-house. |
15846
|
Fri Feb 26 16:31:02 2021 |
gautam | Update | Electronics | Production version of the HV coil driver tested with KEPCO HV supplies |
Koji asked me to test the production version of the coil driver with the KEPCO HV supplies. See Attachment #1 for the results. For comparison, I've added a single trace from the measurements made with the HP supplies. I continue to see excess noise with the KEPCO supplies. Note that in the production version of the board that was tested, there are a pair of 10uF bypass capacitors on the board for the HV supply lines. It is possible that one or both KEPCO supplies are damaged - one was from the ASY setup and one I found in the little rack next to 1X2. The test conditions were identical to that with the HP supplies (as best as I could make it so). |
15847
|
Fri Feb 26 20:20:43 2021 |
Koji | Update | Electronics | Production version of the HV coil driver tested with KEPCO HV supplies |
This is very disappointing. Even with KEPCO linear supply with the improved HV driver circuit, the noise level is significantly higher than the 20kOhm R thermal noise.
What is special with the HP supplies? Can you replace KEPCOs with the HP supply, one by one to specify which one is making the noise bad? |
15848
|
Sat Feb 27 17:25:42 2021 |
gautam | Update | Electronics | Production version of the HV coil driver tested with KEPCO HV supplies |
I will try the test of switching out KEPCOs one at a time for the HP. Given that the passive RC filter doesn't filter out the excess, I am wondering if the KEPCO is somehow polluting the circuit ground? The measurement was made between the circuit side of R24 (see schematic) and a ground testpoint, so the passive R23/C15 pole should filter the noise above ~15 Hz.
Quote: |
This is very disappointing. Even with KEPCO linear supply with the improved HV driver circuit, the noise level is significantly higher than the 20kOhm R thermal noise.
What is special with the HP supplies? Can you replace KEPCOs with the HP supply, one by one to specify which one is making the noise bad?
|
|
16148
|
Thu May 20 16:56:21 2021 |
Koji | Update | Electronics | Production version of the HV coil driver tested with KEPCO HV supplies |
HP HV power supply ( HP6209 ) were returned to Downs |
17107
|
Fri Aug 26 12:46:07 2022 |
Cici | Update | General | Progress on fitting PZT resonances |
Here is an update of how fitting the resonances is going - I've been modifying parameters by hand and seeing the effect on the fit. Still a work in progress. Magnitude is fitting pretty well, phase is very confusing. Attempted vectfit again but I can't constrain the number of poles and zeros with the code I have and I still get a nonsensical output with 20 poles and 20 zeros. Here is a plot with my fit so far, and a zip file with my moku data of the resonances and the code I'm using to plot. |
13939
|
Mon Jun 11 13:55:33 2018 |
keerthana | Update | General | Project Updates |
As of now, I have made the codes needed to sweep the marconi frequency for taking the cavity scan data, the photo diode at the y-end is conected to the spectrum analyser already and I also have the finesse simulation of the Ideal Fabry-perot cavity. By seeing my last elog entry, Gautam suggested me that I need to take a different approach for estimating the FSR and TMS value from the Finesse graph. That is, by using least square fit models. Now I am trying to do that and get a better estimate of the error values. Based on my understanding I am dividing this project into various tasks.
1. Getting a better estimate of the error value by using least square fits. Also plotting a graph of frequency Vs mode number and finding the value of Free Spectral Range from its slop.
2. Inserting zernike polynomials to the Finesse simulation and with the help of least square fit, plotting the graph of frequency Vs mode number. Understanding the shifts from the Ideal graph we obtained from step 1. Using this data, plotting the phase map corresponding to this.
3. Repeating step 2 by taking different zernike polynomials and creating a data base which will be useful for the analysis of the real data. This will also prepare me to do the fitting models easily.
4. Collecting data from the IFO and applying these fitting models to it. Finding the set of zernike polynomials which are similar to the actual fugure error of the mirror. Plotting the Phase map corresponding to those zernike polynomials.
If you feel that there is some mistake in the steps, please correct me. It will be really helpful! |
15226
|
Wed Feb 26 21:43:48 2020 |
Jon | Summary | BHD | Projected IFO noise budget, post-BHD upgrade |
To supplement the material presented during the BHD review, I've put together a projected noise budget for the 40m. Note these are the expected interferometer noises (originating in the IFO itself), not BHD readout noises. The key parameters for each case are listed in the figure title. Also attached is a tarball (attachment 4) containing the ipython notebook, data files, and rolled-back version of pygwinc which were used to generate these figures.
Attachment 1: Phase quadrature readout.
Attachment 2: Comparison to aLIGO design sensitivity (phase quadrature).
Attachment 3: Amplitude quadrature readout. |
15228
|
Wed Feb 26 22:09:52 2020 |
gautam | Summary | BHD | Projected IFO noise budget, post-BHD upgrade |
The quantum noise curves here are not correct. c.f. amplitude quadrature noise budget. |
15241
|
Mon Mar 2 23:49:03 2020 |
Jon | Summary | BHD | Projected IFO noise budget, post-BHD upgrade |
Updated noise budget curves, now computed using the latest version of pygwinc. This resolves the inconsistency between the gwinc quantum noise curves and Gautam's analytic calculations. As before, the key configuration parameters are listed in the figure titles.
Attachment 1: Phase quadrature
Attachment 2: Amplitude quadrature
Attachment 3: Comparison to aLIGO design (phase quadrature)
Quote: |
The quantum noise curves here are not correct. c.f. amplitude quadrature noise budget.
|
|
15244
|
Tue Mar 3 18:11:05 2020 |
Jon | Summary | BHD | Projected IFO noise budget, post-BHD upgrade |
Revised noise estimates, correcting a couple of factor of 2 and factor of pi errors found in the coil driver noise calculation. Also resolves a strain vs. displacement units confusion using the new pygwinc. Gautam and I have checked these noises against the analytical predictions and believe they are now accurate. Attachments are again:
Attachment 1: Phase quadrature
Attachment 2: Amplitude quadrature
Attachment 3: Comparison to aLIGO design (phase quadrature) |
6186
|
Wed Jan 11 21:35:33 2012 |
Max De Jong | Update | General | Projector |
I finished mounting the new projector. The projector and computer monitor now display information. |
4235
|
Tue Feb 1 15:09:41 2011 |
Koji | Omnistructure | General | Projector - fixed |
The projector in the controls room has been fixed the orange blinking of the status LED.
What we needed was to push "Volume -" and "Menu" for 5 sec.
This resets the timer of the lamp. When the timer reaches 2500 hours, it automatically start sabotaging.
We've got the spare lamp. It is in the top drawer of the computer cabinet on which the label makers are. |
8682
|
Wed Jun 5 15:55:16 2013 |
Steve | Update | General | Projector - lightbulb ordered |
Quote: |
Update: We don't have our BIG screen 
There was no light from the projector when I came in this morning. I suspected it might have to do with the lifetime of the bulb. But turning the projector OFF and ON got the projector working....but only for about 10-15 seconds. The display would go OFF after that. I will wait for some additional help to dismount it and check what the problem really is.
|
-
Shipping Estimate Friday June 7, 2013 - Monday June 10, 2013
Delivery Estimate: Wednesday June 12, 2013 - Monday June 17, 2013 by 8:00pm
-
Sold by: Lampedia
|
8688
|
Fri Jun 7 17:12:46 2013 |
gautam | Update | General | Projector - lightbulb replaced |
Quote: |
Quote: |
Update: We don't have our BIG screen 
There was no light from the projector when I came in this morning. I suspected it might have to do with the lifetime of the bulb. But turning the projector OFF and ON got the projector working....but only for about 10-15 seconds. The display would go OFF after that. I will wait for some additional help to dismount it and check what the problem really is.
|
-
Shipping Estimate Friday June 7, 2013 - Monday June 10, 2013
Delivery Estimate: Wednesday June 12, 2013 - Monday June 17, 2013 by 8:00pm
-
Sold by: Lampedia
|
[manasa, gautam]
-the replacement lamp arrived a while back.
-the old lamp has been switched out, it had 3392 lamp hours on it.
-new lamp installed, projector mounted back up, and lamp hours reset to zero. there is a lingering odour of something burning, not sure what it is or if it is in any way connected to the new lamp. old lamp disposed in the hazardous waste bin. the big screen is back online. |
8690
|
Fri Jun 7 23:44:54 2013 |
Koji | Update | General | Projector - lightbulb replaced |
http://nodus.ligo.caltech.edu:8080/40m/7885 |
9504
|
Fri Dec 20 17:41:25 2013 |
Steve | Update | General | Projector - lightbulb replaced |
The lamp lasted for 4,622 hours.
This time I purchased just the bare lamp itself . The housing doubles the price. The disadvantage of this technic that the lamp housing window can not be cleaned perfectly. Atm2 picture is exaggerating this spot.
However, It does not degrade the image quality.
Roll over image to zoom in
Glamps RLC-061 Projector Original Bulb Lamp for VIEWSONIC Pro8200 Pro8300
|
8675
|
Wed Jun 5 10:22:12 2013 |
Manasa | Update | General | Projector - viewsonic |
Update: We don't have our BIG screen 
There was no light from the projector when I came in this morning. I suspected it might have to do with the lifetime of the bulb. But turning the projector OFF and ON got the projector working....but only for about 10-15 seconds. The display would go OFF after that. I will wait for some additional help to dismount it and check what the problem really is.
|
6507
|
Sat Apr 7 02:01:29 2012 |
Mike J. | Update | Computers | Projector Cable Management |
I replaced the projector video and power cables with longer ones, and zip-tied them to the ceiling and wall so they don't block the image.

|
12913
|
Tue Mar 28 16:47:40 2017 |
Steve | Update | safety | Projector bulb is out again |
Three replacement bulbs ordered
Rana can discribe how it happened.
IF A LAMP EXPLODES
If a lamp explodes, the gas and broken shards may scatter inside the projector and they may comeout of the exhaust vent.
The gas contains toxic mercury.
Open windows and doors for ventilation.
If you inhale the gas or the shardsof the broken lamp enter your eyes or mouth, consult the doctorimmediately.
Quote: |
This bulb was blown out on Feb 4, 2017 after 2 months of operation.
|
|
12927
|
Tue Apr 4 11:24:21 2017 |
Steve | Update | safety | Projector bulb is out again |
Shipped out for repair.
Quote: |
Three replacement bulbs ordered
Rana can discribe how it happened.
IF A LAMP EXPLODES
If a lamp explodes, the gas and broken shards may scatter inside the projector and they may comeout of the exhaust vent.
The gas contains toxic mercury.
Open windows and doors for ventilation.
If you inhale the gas or the shardsof the broken lamp enter your eyes or mouth, consult the doctorimmediately.
Quote: |
This bulb was blown out on Feb 4, 2017 after 2 months of operation.
|
|
It is back and running fine witth bulb 4-13-2017 |
12843
|
Tue Feb 21 17:05:14 2017 |
Steve | Update | General | Projector lamp replaced |
This bulb was blown out on Feb 4, 2017 after 2 months of operation.
|
14046
|
Mon Jul 9 12:36:32 2018 |
pooja | Update | General | Projector light bulb blown out |
Projector light bulb blown out today. |
14739
|
Tue Jul 9 18:17:48 2019 |
gautam | Update | General | Projector lightbulb blown out |
Last documented replacement in Nov 2018, so ~7 months, which I believe is par for the course. I am disconnecting its power supply cable. |
14743
|
Wed Jul 10 14:55:32 2019 |
Koji | Update | General | Projector lightbulb blown out |
In fact the projector is still working. The lamp timer showed ~8200hrs. I just reset the timer, but not sure it was the cause of the shutdown. I also set the fan mode to be "High Altitude" to help cooling. |
14752
|
Thu Jul 11 16:22:54 2019 |
Kruthi | Update | General | Projector lightbulb blown out |
I heard a popping sound in the control room; the projector lightbulb has blown out. |
14777
|
Fri Jul 19 15:51:55 2019 |
gautam | Update | General | Projector lightbulb blown out |
[chub, gautam]
Bulb replaced. Projector is back on. |
12837
|
Fri Feb 17 20:04:43 2017 |
Koji | Update | General | Projector not functional / Zita partially working |
Koji, Gautam, Johannes
We quickly checked the situation of the projector in the control room.
- We found that the proejctor was indicating "lamp error".
==> Steve, could you remove the projector from the ceiling and check if it still does not work?
If it still does not work, send it back to the vender. It should be covered by the previous service.
- Zita seemed happy with the DVI output. We tried the dual display configration and VGA and DVI are active right now.
The DVI output (from RADEON something video card) is somewhat strange. We probably need to look into the video display situation. |
13496
|
Tue Jan 2 16:24:29 2018 |
gautam | Update | safety | Projector periodically shuts itself off |
I noticed this behaviour since ~Dec 20th, before the power failure. The bulb itself seems to work fine, but the projector turns itself off after <1 minute after being manually turned on by the power button. AFAIK, there was no changes made to the projector/Zita. Perhaps this is some kind of in-built mechanism that is signalling that the bulb is at the end of its lifetime? It has been ~4.5 months (3240 hours) since the last bulb replacement (according to the little sticker on the back which says the last bulb replacement was on 15 Aug 2017 |
14516
|
Fri Apr 5 00:33:58 2019 |
gautam | Update | ALS | Promising IR ALS noise |
Summary:
I set up a free-space beat on theNW side of the PSL table between the IR beam from the PSL and from EX, the latter brought to the PSL table via ~40m fiber. Initial measurements suggest very good performance, although further tests are required to be sure. Specifically, the noise below 10 Hz seems much improved.
Details:
Attachment #1 shows the optical setup.
- I used two identical Thorlabs F220APC collimators to couple the light back into free space, reasoning that the mode-matching would be easiest this way.
- Only 1 spare K6Xs collimator mount was available (this has the locking nut on the rotational DoF), so I used a K6X for the other mount. The fast axis of the Panda fibers were aligned as best as possible to p-polarization on the table by using the fact that the connector key is aligned to the slow axis.
- I cut the power coupled into the PSL fiber from ~2.6mW to ~880uW (using a HWP + PBS combo before the input coupling to the fiber) to match the power from EX.
- The expected signal level from these powers and the NF1611 transimpedance of 700 V/A is ~320 mVpp. After alignment tweaking, I measured ~310mVpp (~ -5dBm) into a 50 ohm input on a scope, so the mode-matching which means the polarization matching and mode overlap between the PSL and EX beams are nearly optimal.
- To pipe the signal to the delay line electronics, I decided to use the ZHL-3A (G=27dB, 1dB compression at 29.5dBm per spec), so the signal level at the DFD rack was expected (and confirmed via 50 ohm input on o'scope) to be ~19dBm.
- This is a lot of signal - after the insertion loss of the power splitter, there would still be ~15dBm of signal going to the (nominally 10dBm) LO input of the demod board. This path has a Teledyne AP1053 at the input, which has 10dB gain and 1dBm compression at 26dBm per spec. To give a bit of headroom, I opted on the hacky solution of inserting an attenuator (5dB) in this path - a better solution needs to be implemented.
- The differential outputs of the demod board go to the CDS system via an AA board (there is no analog whitening).
Yehonathan came by today so I had to re-align the arms and recover POX/POY locking. This alllowed me to lock the X arm length to the PSL frequency, and lock the EX green laser to the X arm length. GTRX was ~0.36, whereas I know it can be as high as 0.5, so there is definitely room to improve the EX frequency noise suppression.
Attachment #2 shows the ALS out-of-loop noise for the PSL+X combo. The main improvements compared to this time last year are electronic.
- The failed experiment of making custom I/F amplifier was abandoned and Rich Abbott's original design was reverted to.
- New power splitter was installed with 3dB less insertion loss.
- According to the RF path level monitor, the signal level at the RF input to the demod board is ~10dBm. Per my earlier characterization, this will give us the pretty beefy frequency discriminant of ~15uV/Hz.
- I estimate the frequency noise of the detection electronics + ADC noise now translate to 1/3 the frequency noise compared to the old system. With some analog whitening, this can be made even better, the electronics noise of the DFD electronics (~50nV/rtHz) is estimated to be <10mHz/rtHz equivalent frequency noise.
- Note that the calibration from phase-tracker-servo to units of Hz (~14 kHz / degree) was not changed in the digital system - this should only be a property of the delay line length, and hence, should not have changed as a result of the various electronics changes to the demod board and other electronics.
Next steps:
- Improve pointing of green beam into X arm cavity.
- I plan to recover the green beat note as well and digitize it using the second available DFD channel (eventually for the Y arm) - then we can simultaneously compare the the green and IR performance (though they will have different noise floors as there is less green light on the green beat PDs, and I think lower transimpedance too).
Quote: |
Mix the beams in free space. We have the beam coming from EX to the PSL table, so once we mix the two beams, we can use either a fiber or free-space PD to read out the beatnote.
- This approach means we lose some of the advantages of the fiber based setup (e.g. frequent alignment of the free-space MM of the two interfering beams may be required).
- Potentially increases sensitivity to jitter noise at the free-space/fiber coupling points
|
|
5020
|
Fri Jul 22 17:01:41 2011 |
Iron Man | Frogs | General | Proof that Alberto lived through his Iron Man! |
 
 |
208 |
Alberto |
Stochino |
67/129 |
585/1376 |
36:02 |
1:52 |
830 |
6:41 |
2:38:58 |
21.1 |
296 |
4:58 |
56:33 |
2:13:40 |
- |
5:40:19 |
|
13717
|
Thu Mar 29 12:03:37 2018 |
Jon Richardson | Summary | General | Proof-of-Concept SRC Gouy Phase Measurement |
I've been developing an idea for making a direct measurement of the SRC Gouy phase at RF. It's a very different approach from what has been tried before. Prior to attempting this at the sites, I'm interested in making a proof-of-concept measurement demonstrating the technique on the 40m. The finesse of the 40m SRC will be slightly higher than at the sites due to its lower-transmission SRM. Thus if this technique does not work at the 40m, it almost certainly will not work at the sites.
The idea is, with the IFO locked in a signal-recycled Michelson configuration (PRM and both ETMs misaligned), to inject an auxiliary laser from the AS port and measure its reflection from the SRC using one of the pre-OMC pickoff RFPDs. At the sites, this auxiliary beam is provided by the newly-installed squeezer laser. Prior to injection, an AM sideband is imprinted on the auxiliary beam using an AOM and polarizer. The sinusoidal AOM drive signal is provided by a network analyzer, which sweeps in frequency across the MHz band and demodulates the PD signal in-phase to make an RF transfer function measurement. At the FSR, there will be a AM transmission resonance (reflection minimum). If HOMs are also present (created by either partially occluding or misaligning the injection beam), they too will generate transmission resonances, but at a frequency shift proportional to the Gouy phase. For the theoretical 19 deg one-way Gouy phase at the sites, this mode spacing is approximately 300 kHz. If the transmission resonances of two or more modes can be simultaneously measured, their frequency separation will provide a direct measurement of the SRC Gouy phase.

The above figure illustrates this measurement configuration. An attached PDF gives more detail and the expected response based on Finesse modeling of this IFO configuration. |