Here is the fft of the output of the Isomet oscillator (10mW output power, with a 50ohm attenuator on the frequency modulation input). The input of the spectrum analyser had the input attenuator set to 20dB.
I centered the measurement around the oscillator frequency (approx 30MHz). We see large peaks every 132kHz and smaller sidebands on each of these.
Although this is bad, I'm not sure that this is the issue. We'll have to diagnose it on the bench, but I think it just may be the way you guys were powering it.
Those lines are probably from the switching power supply; the type of RF amplifier that's in there probably has no power supply rejection at all. We'd be
much better off powering this thing from a real, regulated DC power source and then make sure to put the bypass capacitors (one big, one small) right on the power pins of the AOM driver.
Agreed we didn't have the capacitors right up against the AOM driver. They were on the power supply, and the large ones could be bigger.
However we did try it with a second totally different style of power supply, and the frequency of the lines was exactly the same. It will be interesting to see whether a regulated supply gets rid of them.
We have large glass jugs of methanol and acetone - we need one of isopropyl too. I'm not sure how to go about this.
One in the TCS Lab. One by the ATF door. I have more ant bait available in the TCS Lab.
Item lending as per Ian's request: Particle Counter from OMC Lab to QIL
The current particle class of the room was measured to be 800.
The particle counter went back to the OMC lab on Aug 10, 2020.
Still trying to figure out how to set up the particle counter remotely. The current particle count is 576.
Note: the particle count is the number of particles detected over 0.3um size.
Okay - all the steps in the procedure of eLOG 2476 have been verified as working - with the exception of the RTDs in the chamber.
With regards to taking dark noise spectra at different biases and temperatures, looks like Raymond took spectra with biases of [50, 100, 200, 400, 600, 1000]mV. If no objections, I’ll stick to that number of measurements.
I’m a bit pushed for time with other stuff. I wonder if the shield RTD is sufficient to run tests on the system? I’ll go back through the data and see how reproducible the relationship between shield temperature and PD temperature is. If it is reliable then in the interests of time, I’m going to forgo re-installing the extra RTDs in the chamber just now.
Looks like the temperature difference between the PD and the shield is relatively small. Even the transients when the heater is applied are order 5K.
This means that, for quick purposes, the shield RTD is a good proxy for the PD temperature.
The attached data is the difference between PD and shield RTD from circa 5th-6th February 2020.
I recorded a 15 minute overview that describes the JPL PD set up and how to operate it. I'm in the process of embellishing the operation procedure (previous version can be found here: eLOG 2476).
[Returned] Brought one HAM-A coil driver (D1100687 / S2100619) and one Satellite Amplifier (D1002818 / S2100741) from the 40m
Also brought some power cables.
Brought ~1m of 0.0017" (~43um) misical wire. This will make the tension stress be 341MPa. The safety factor will be ~7.
The keys to the 35W (as well as the gyro laser) have been removed. There is no elog entry saying who did this, where they are, or when it happened.
[Edit: We found it in one of the drawers of the console tables!]
- for personal use only -
I've returned the Keithley Source Meter unit
- The unit (Keithley 2450?2460?)
- A power cable
- A pair of banana clips
- the transistor test fixture & triax cable/connectors
Note that the back panel connectors are Triax, not the usual Coax.
I added some EPICS channels to the Hartmann sensor softIoc and then added these to be recorded in the frames.
I then killed the daqd process on fb1 so it would start afresh.
I killed and restarted the daqd process because I wanted to add some 16Hz TCS channels to the frame builder. These are from the Athena DAQ box.
I edited the following files:
We are continuing the naming scheme with CX? I thought we were planning on making C2 the whole subbasement...
Nope. Each lab has its own number. I think PSL is C3, TCS is C4, ATF gets C2....Frank has the full listing of these things. Or at least that's the latest I heard a few months ago after several elogs back and forth.
Right - I am questioning the scalability and sense of this scheme, and inquiring if this is aesthetic.... i.e. is there a reason it cannot be C2SYS for all of bridge, (possibly front end naming limitations)?
I have run the design rule check on the new PCB and there are no violations. I am going to do one last run of checking dimensions (hole placement, BNC mount clearance, etc.) and then generate files. Once I have them, provided there are no more comments, I will take them to Steve or someone to purchase.
I thought of a primitive device that could be used as a frequency discriminator in our (and similar) readouts. It is sort of like the "cable" method championed earlier this year, only instead of using an asymmetric michelson style setup for the phase shift, one uses a high-Q LC filter tuned to the carrier in one path, as below:
As the signal from the PD changes frequency, the phase shift from the LC filter changes, providing a linear output from the mixer proportional to the frequency shift. Using high-enough-quality components (DCR ~ 50 mOhm), we can get discriminants approaching 1 mrad/Hz, which would require hundreds of km of cable in the other case.
Feeding to the LO with the LC leg ensures that AM from the filter---which is already higher than first-order---is removed.
There are two probable issues:
I talked to Frank before thinking about this much further, and he didn't think there was anything obviously wrong with the idea. To the contrary, he thought it might be worth looking at because it could be useful for other experiments. I don't think we have good enough components to try this yet. We may have some good capacitors somewhere, and Frank mentioned that we might have a DIY inductor kit, so that's promising. Otherwise, I think we might want to order some good high-Q components and try this out.
The reason I went for cable length instead of LC, is that the LC is basically a version of a VCO with a PLL, except that the VCO is made of macroscopic L & C. I think the only way to be
sure about the performance is just to build it and see. But basically, you can be sure that you have to ovenize the LC and pack it with putty. Might as well get yourself warmed up for some
ovenizing one way or another: gyro, table, EOM, LC, etc.
Yes, I can see that. I also figured it was because the intended purpose of the cable method was to measure much larger frequency shifts, not mHz-level. So they shouldn't really be compared directly.
I'm building a simple LC to see how it performs. If it does even close to well then maybe I'll order some nicer parts.
Over the past couple days (in between overhauling malfunctioning PDs), we have been trying to hunt down the excess low-frequency noise. Last week, with Koji's help, we essentially ruled out the possibility of scattered light noise from the transmitted end of the gyro by intentionally reflecting varying amounts of light back into the cavity and observing NO DIFFERENCE in the low-frequency spectrum.
AM from the EOM still seems to be the most likely suspect, and we continue to find ways in which it could couple. Yesterday, we think we traced the crazy AM level modulation that I mentioned in my last post to the iris we are using to isolate the proper beam out of the AOM setup. The double-1st order (desired) and single-1st order (undesired) beams are extremely difficult to isolate from one another, so we had to use a very small aperture that we think was coupling EOM jitter into AM quite strongly. We moved the iris down the beam path closer to the waist(s) and were able to get better isolation with a larger aperture. The drift in AM level now seems absent.
While the AM levels in the CCW and CW beams (as measured on the RF analyzer) are not simultaneously minimized at the same pre-EOM HWP angle, there is no longer a large-angle discrepancy; the difference is <1 degree and the noise in both beams can now be kept fairly low at some compromise angle. I have set up a PDA255 in each path immediately before the cavity to monitor them both simultaneously. By adjusting the HWP before the EOM and fine-tuning the EOM orientation, I was able to get the AM peaks in both beams to be <10 ppm relative to the carrier.
After re-locking the gyro, I saw NO IMPROVEMENT in the low-frequency noise yet again. I replaced the PDA255s and tried looking at the LF noise directly after demodulation. I saw some excess noise above the broadband floor below about 1 Hz, which is roughly where the excess gyro noise begins. Upon deliberately de-tuning the HWP so that the RF peaks were >20x higher, however, I saw NO NOTICEABLE CHANGE in the audio spectrum. Looking at the peaks in the RF spectrum more closely, I discovered that the linewidths are below 1 Hz, suggesting that this may not be the source after all.
I suggest that we vent the chamber and obstruct the cavity so that we can run the same tests with the REFL PDs themselves. Then, we can use the noise we measure in the error signal to easily and accurately estimate the contribution to the NB.
The low frequency noise is still present in the TRANS signal, seemingly discounting the beam jitter theory. I think I am too sad to ask Rana for the $5, though.
I am still absolutely stumped about the LF noise. Today I revisited and reconfirmed the fact that the gyro noise is strongly correlated with the noise in the DC_TRANS level at low frequencies:
What this means remains a mystery to me. I also re-verified that the laser power fluctuations do not have the right shape to explain this noise (nor is there an obvious coupling from laser intensity noise to gyro noise in this case). The fact that we have ruled out traditional RAM as the source makes it anyone's guess as to what's happening here. Increasing the LF common-mode gain by ~50 has zero effect on either the gyro noise or the DC_TRANS noise.
I am pointing out the DC_TRANS correlation again because I think it is a potential smoking gun. If you or someone you know has any information regarding this matter please call 1-800-GYRO-WTF.
I replaced the LT1128 in the whitening filter for channel B with one from Downs, to see if it exhibited better low-frequency current noise. It did, but only very marginally:
The Downs part is about a factor of sqrt(2) better, but even it is not appreciably below the "max" estimate from LISO. However, the fact that the noise improves slightly here (and nowhere else) when that one LT1128 is replaced only strengthens my suspicion that this is indeed just bad current noise performance from the LT1128.
In fact, if you look at the performance of the aLIGO in-vacuum DCPD preamps, which have essentially same LT1128 whitening stages as I used in the M2 (actually 2 in series), you see a similar amount of excess low-frequency noise. Here is a measurement of one DCPD I made while at LLO, compared with LISO estimates using the "typical" and "maximum" noise specs for the LT1128:
As you can see, the data match the "max" curve very well. So, either a.) Linear is pulling a fast one on us and under-reporting the typical current noise or b.) we are doing something silly with the circuit, and this is somehow perfectly mimicking a "max" current noise part.
For a while now I've wondered how LTSpice thinks the the AD829 should perform around 1 MHz. To that end, I ran simulations of an AD829 inverter for a few different gain/compensation settings.
This is also of potential interest to the 40m and cryo, both of whom may want to construct detailed phase budgets in the region from 100 kHz to a few megahertz.
As a reminder, this is how Analog Devices thinks we should stuff the AD829:
What I simulated was slightly different:
Here R3 means I've added a resistor from the (+) pin to gnd, in order to cancel some of the bias current.
For each gain, I ran the simulation with both a 50 Ω load and a 1 MΩ load. In the attached zip file you can find screenshots of the Spice model for each gain setting.
Visitors to the lab ...
A 121307 161942 0100 0.3 000000 0.5 000000 TMP 000680 R/H 000130 LOC 000000 C/S 000E54
A 121307 164641 0100 0.3 000000 0.5 000000 TMP 000680 R/H 000130 LOC 000000 C/S 000E53
A 121307 171340 0100 0.3 000000 0.5 000000 TMP 000685 R/H 000130 LOC 000000 C/S 000E52
A 121307 174039 0100 0.3 000000 0.5 000000 TMP 000680 R/H 000200 LOC 000000 C/S 000E53
A 121307 180738 0100 0.3 000000 0.5 000000 TMP 000680 R/H 000210 LOC 000000 C/S 000E57
A 121307 183437 0100 0.3 000000 0.5 000000 TMP 000680 R/H 000210 LOC 000000 C/S 000E56
A 121307 190136 0100 0.3 000000 0.5 000000 TMP 000680 R/H 000195 LOC 000000 C/S 000E5C
A 121307 192835 0100 0.3 000000 0.5 000000 TMP 000685 R/H 000195 LOC 000000 C/S 000E69
When I went into QIL today there was a lot of flooding from water dripping from the ceiling at several places in the lab. Images attached.
Some photos of affected areas in B265A and B265B (elog shows some preview photos - click on PDF for full set).
Stephen did a great job cleaning up and drying up. Most equipment is powered off and we're leaving it off for a couple of days to dry completely. We'll want to check the stuff on the red lab cart thoroughly.
Flood photo album: https://photos.app.goo.gl/BZAG8DyQzFVTfMNz6 (This link is read-only who has no access to the account)
Facilities placed a blower and dehumidifier in B265B. I checked the airflow and the air around the tables is comparitively still. The North table is covered and the South table is over pressurized by HEPA filters, so there should be little risk of dust being stirred up.
This morning, facilities removed all the porous ceiling panels that had been soaked/damaged by water (in B265B: above WS1 and WS2, see Attachments 1+2; In B265A, see Attachment 3). Specifically in B265A, an enclosure was created (Attachment 4) and a dehumidifier was placed inside. All monitors/equipment underneath the panels were thoroughly covered, and the floors were swept up afterward.
No work was done above the North table in the QIL. I asked about it and facilities said they would look into it, but it wasn't on the schedule for today. A member of facilities also pointed out that the sink in the QIL was running black liquid (Attachment 5). It looks like soil/dirt entered the water pipes? This seemed to also be outside of their scope for today.
Muddy Waters is not new, but if the facility can fix it we'd take it.
Facilities will be returning on Monday 4/4 between 8-9 AM to remove all ceiling panels above the workstations in B265B (QIL). Replacement of the panels is not yet scheduled, but in the meantime the open ceiling will be covered and the workstations will still be accessible.
Pictures attached. WS1 and WS2 have been turned back on, since the replacement for the ceiling panels will not arrive for another few weeks according to Facilities.
Yesterday there was flooding in the lab (coming from the roof). Tables were covered to prevent drips from getting on optics and other electronics and items were removed to the TCS lab. We should maybe consider improving the air gap between plastic covering the tables so that residual moisture is not trapped in there.
When I went in this morning all of the water on the floor had dried up and humidity was down to 13% (as reported on a cheap temp/humidity unit we have down there).
AC control issues
The AC unit that was malfunctioning last week is now putting out 30.2C air again. This is with thermostats for both units set to 70F. Airflow also seems lower than before. Its possible that the flooding has triggered some other issue. I have logged a job with Facilities (REF AiM Request No: 8982). I asked if they could fix it today, but if they come later in the week someone will need to let them in as I am away.
Someone has come around to look at the AC. The guy told me the thermostate was just set wrong, but the reading on the front was 70F when I looked and it was definitly not putting out that. It may be that the unit sticks sometimes. Next time there is an issue try changing the temperature to see if it triggers a change. If this is persistant we may need to get the whole thermostate switched out.
Some of the circuits around the lab were shutdown. I have turned on #22 to boot up ws2 to see if I could ping it from the PSL lab. If no power, check at the breaker box.
Need to have a couple of room temperature sensors logged into the frames so that we can do long term lookback of the lab temperature.
What about those environmental sensors that Frank Seifert setup and Aidan or Antonio revived ?
Believe its just waiting a frame builder and maybe a license: https://nodus.ligo.caltech.edu:8081/PSL_Lab/1716
Also the batteries on these units seem to do about 1-1.5 months. Someone needs to check on a regular basis they are still running.