This afternoon I started setting up the Supermicro 5017A-EP that will replace c1vac1/2. Following Johannes's procedure in 13681 I installed Debian 8.11 (jessie). There is a more recent stable release, 9.5, now available since the first acromag machine was assembled, but I stuck to version 8 for consistency. We already know that version to work. The setup is sitting on the left side of the electronics bench for now.
Today I finished setting up the server that will replace the c1vac1/2 machines. I put it on the martian network at the unassigned IP 192.168.113.72. I assigned it the hostname c1vac and added it to the DNS lookup tables on chiara.
I created a new targets directory on the network drive for the new machine: /cvs/cds/caltech/target/c1vac. After setting EPICS environment environment variables according to 13681 and copying over (and modifiying) the files from /cvs/cds/caltech/target/c1auxex as templates, I was able to start a modbusIOC server on the new machine. I was able to read and write (soft) channel values to the EPICS IOC from other machines on the martian network.
I scripted it as a systemd-managed process which automatically starts on boot and restarts after failure, just as it is set up on c1auxex.
Wiring of the power, Ethernet, and indicator lights for the vacuum Acromag chassis is complete. Even though this crate will only use +24V DC, I wired the +/-15V connector and indicator lights as well to conform to the LIGO standard. There was no wiring diagram available, so I had to reverse-engineer the wiring from the partially complete c1susaux crate. Attached is a diagram for future use. The crate is ready to begin software developing on Monday.
All 7 Acromag units are now installed in the vacuum chassis. They are connected to 24V DC power and Ethernet.
I have merged and migrated the two EPICS databases from c1vac1 and c1vac2 onto the new machine, with appropriate modifications to address the Acromags rather than VME crate.
I have tested all the digital output channels with a voltmeter, and some of the inputs. Still more channels to be tested.
I’ll follow up with a wiring diagram for channel assignments.
I've set up a closed subnetwork for interfacing the vacuum hardware (Acromags and serial devices) with the new controls machine (c1vac; 192.168.113.72). The controls machine has two Ethernet interfaces, one which faces outward into the martian network and another which faces the internal subnetwork, 192.168.114.xxx. The second network interface was configured via the following procedure.
1. Add the following lines to /etc/network/interfaces:
iface eth1 inet static
2. Restart the networking services:
$sudo /etc/init.d/networking restart
3. Enable DNS lookup on the martian network by adding the following lines to /etc/resolv.conf:
4. Enable IP forwarding from eth1 to eth0:
$sudo echo 1 > /proc/sys/net/ipv4/ip_forward
5. Configure IP tables to allow outgoing connections, while keeping the LAN invisible from outside the gateway (c1vac):
$sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
$sudo iptables -A FORWARD -i eth0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
$sudo iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT
6. Finally, because the EPICS 3.14 server binds to all network interfaces, client applications running on c1vac now see two instances of the EPICS server---one at the outward-facing address and one at the LAN address. To resolve this ambiguity, two additional enviroment variables must be set that specify to local clients which server address to use. Add the following lines to /home/controls/.bashrc:
A list of IP addresses so far assigned on the subnetwork follows.
I've completed bench testing of all seven vacuum Acromags installed in a custom rackmount chassis. The system contains five XT1111 modules (sinking digital I/O) used for readbacks of the state of the valves, TP1, CP1, and the RPs. It also contains two XT1121 modules (sourcing digital I/O) used to pass 24V DC control signals to the AC relays actuating the valves and RPs. The list of Acromag channel assignments is attached.
I tested each input channel using a manual flip-switch wired between signal pin and return, verifying the EPICS channel readout to change appropriately when the switch is flipped open vs. closed. I tested each output channel using a voltmeter placed between signal pin and return, toggling the EPICS channel on/off state and verifying the output voltage to change appropriately. These tests confirm the Acromag units all work, and that all the EPICS channels are correctly addressed.
New hardware has been installed in the vacuum controls rack. It is shown in the below post-install photo.
Below is a high-level summary of where things stand, and what remains to be done.
✔ Set up of replacement controls server (c1vac).
✔ Set up of Acromag terminals.
✔ EPICS database migration.
✔ Set up of 16-port IOLAN terminal server (for multiplexing/Ethernetizing the serial devices).
All the serial vacuum signals are now interfaced to the new digital controls system. A set of persistent Python scripts will query each device at regular intervals (up to ~10 Hz) and push the readings to soft channels hosted by the modbus IOC. Similar scripts will push on/off state commands to the serial turbo pumps.
Each serial device is assigned an IP address on the local subnet as follows. Its serial communication parameters as configured in the terminal server are also listed.
The foam in the cable tray wall passage had been falling on the floor in little bite-sized pieces, so I investigated and found a fiber cable that had be chewed/clawed through. I didn't find any droppings anywhere in the 40m, but I decided to bait an un-set trap and see if we'd find activity around it. There has been none so far. If there is still none tomorrow, I will move the trap and keep looking for signs of rodentia. At the moment, the trap is in a box in front of the double doors at the north end of the control room. Next it will be place in the IFO room, up in the cable tray.
gautam: the fiber that was damaged was the one from the LSC rack FiBox to the control room FiBox. So no DAFI action for a bit...
I added lubricating oil to roughing pumps RP1 and RP3 yesterday and this morning. Also, I found a nearly full 5 gallon jug of grade 19 oil in the lab. This should set us up for quite a while. If you need to add oil the the roughing pumps, use the oil in the quart bottle in the flammables cabinet. It is labeled as Leybold HE-175 Vacuum Pump Oil. This bottle is small enough to fill the pumps in close quarters.
The Central Plant building will be undergoing seismic upgrades in the near future. The adjoining north wall along the Y arm will be the first to have this work done, from inside the Central Plant. Project manager Eugene Kim has explained the work to me and also noted our concerns. He assured me that the seismic noise from the construction will be minimized and we will always be contacted when the heaviest construction is to be done.
Tomorrow at 11am, I will bring Mr. Kim and a few others from the construction team to look at the wall from inside the lab. If you have any questions or concerns that you want to have addressed, please email them to me or contact Mr. Kim directly at x4860 or through email at firstname.lastname@example.org .
The schematic of the homodyne configuration is shown below.
Following are the list of components
One set of fiber is now kept along the arm of the interferometer
Fiber coupled (3 No's)
Free space ( 2 No's)
I went through all the elog entries related to CCD calibration. I was wondering if we can use Spectralon diffuse reflectance standards (https://www.labsphere.com/labsphere-products-solutions/materials-coatings-2/targets-standards/diffuse-reflectance-standards/diffuse-reflectance-standards/) instead of a white paper as they would be a better approximation to a Lambertian scatterer.
On calculating the accessible u-v ranges and the % error in magnification (more precisely, %deviation), I got %deviation of order 10 and in some cases of order 100 (attachments 1 to 4), which matches with Pooja's calculations. But I'm not able reproduce Jigyasa's %error calculations where the %error is of order 10^-1. I couldn't find the code that she had used for these calculations and I even mailed her about the same. We can still image with 150-250 mm combination as proposed by Jigyasa, but I don't think it ensures maximum usage of pixel array. Also for this combination the resulting conjugate ratio will be greater than 5. So, use of plano-convex lenses will reduce spherical aberrations. I also explored other focal length combinations such as 250-500 mm and 500-500mm. In these cases, both the lenses will have f-numbers greater than 5. But the conjugate ratios will be less than 5, so biconvex lenses will be a better choice.
Constraints: available lens tube length (max value of d) = 3" ; object distances range (u) = 70 cm to 150 cm ; available cylindrical enclosures (max value of d+v) are 52cm and 20cm long (https://nodus.ligo.caltech.edu:8081/40m/13000).
I calculated the resultant image distance (v) and the required distance between lenses (d), for fixed magnifications (i.e. m = -0.06089 and m = -0.1826 for imaging test masses and beam spot respectively) and different values of 'u'. This way we can ensure that no pixels are wasted. The focal length combinations - 300-300mm (for imaging beam spot), and 100-125mm (for imaging test masses) - were the only combinations that gave all positive values for 'd' and 'v', for given range of 'u' (attachments 5-6). But here 'd' ranges from 0 to 30cm in first case, which exceeds the available lens tube length. Also, in the second case the f-numbers will be less than 5 for 2" lenses and thus may result in spherical aberration.
All this fuss about f-numbers, conjugate ratios, and plano-convex/biconvex lenses is to reduce spherical aberrations. But how much will spherical aberrations affect our readings?
We have two 2" biconvex lenses of 150mm focal length and one 2" biconvex lens of focal length 250mm in stock. I'll start off with these and once I have a metric to quantify spherical aberrations we can further decide upon lenses to improve the telescopic lens system.
Went through all of Pooja's elog posts, her report and am currently cleaning up her code and working on setting up the simulations of spot motion from her work last year. I've also just begun to look at some material sent by Gautam on resonators.
This week, I plan to do the following:
1) Review Gabriele's CNN work for beam spot tracking and get his code running.
2) Since the relation between the angular motion of the optic and beam spot motion can be determined theoretically, I think a neural network is not mandatory for the tracking of beam spot motion. I strongly believe that a more traditional approach such as thresholding, followed by a hough transform ought to do the trick as the contours of the beam spot are circles. I did try a quick and dirty implementation today using opencv and ran into the problem of no detection or detection of spurious circles (the number of which decreased with the increased application of median blur). I will defer a more careful analysis of this until step (1) is done as Gautam has advised.
3) Clean up Pooja's code on beam tracking and obtain the simulated data.
4) Also data like this (https://drive.google.com/file/d/1VbXcPTfC9GH2ttZNWM7Lg0RqD7qiCZuA/view) is incredibly noisy. I will look up some standard techniques for cleaning such data though I'm not sure if the impact of that can be measured until I figure out an algorithm to track the beam spot.
A more interesting question Gautam raised was the validity of using the beam spot motion for detection of angular motion in the presence of other factors such as surface irregularities. Another question is the relevance of using the beam spot motion when the oplevs are already in place. It is not immediately obvious to me how I can ascertain this and I will put more thought into this.
I'm not able to get trends of the TM adjustment test that Rana had asked us to perform, from the dataviewer. It's throwing the following error:
Connecting to NDS Server fb (TCP port 8088)
Server error 7: connect() failed
datasrv: DataWrite failed: daq_send: Resource temporarily unavailable
T0=19-07-20-01-27-39; Length=600 (s)
No data output.
What channels are you trying to read?
Connecting to NDS Server fb (TCP port 8088)
Server error 7: connect() failed
datasrv: DataWrite failed: daq_send: Resource temporarily unavailable
T0=19-07-20-01-27-39; Length=600 (s)
No data output.
Still removing old cable, terminal blocks and hardware. Once new strain reliefs and cable guides are in place, I will need to disconnect cables and reroute them. Please let me know dates and times when that is not going to interrupt your work!
In order to measure the loss in the arm cavities in reflection, we use the DC method described in T1700117.
It was not trivial to find free channels on the LSC rack. The least intrusive way we found was to disconnect the ALS signals DSUB9 (Attachment 1) and connect a DSUB breakout board instead (Attachment 2).
The names of the channels are ALS_BEATY_FINE_I_IN1_DQ for AS reflection and ALS_BEATY_FINE_Q_IN1_DQ for MC transmission. Actually, the script that downloads the data uses these channels exactly...
We misalign the Y arm (both ITM ad ETM) and start a 30 rep measurement of the X arm loss cavity using /scripts/lossmap_scripts/armLoss/measureArmLoss.py and download the data using dlData.py.
We analyze the data. Raw data is shown in attachment 3. There is some drift in the measurement, probably due to drift of the spot on the mirror. We take the data starting from t=400s when the data seems stable (green vertical line). Attachment 5 shows the histogram of the measurement
X Arm cavity RT loss calculated to be 69.4ppm.
We repeat the same procedure for the Y Arm cavity the day after. Raw data is shown in attachment 5, the histogram in attachment 6.
Y Arm cavity RT loss calculated to be 44.8ppm. The previous measurement of Y Arm was ~ 100ppm...
Loss map measurement is in order.
As requested, I placed an order for an assortment of new RF cables: SMA male-male, RG405.
They're expected to arrive mid next week.
I re-ordered the below cables, this time going with flexible, double-shielded RG316-DS. Jordan will pick up and return the RG-405 cables after the holidays.
Our favorite (flexible) RF cable is Belden's 1671J (Jacketed solder-soaked coax cable). It is compatible RG405. I'm not sure if there is off-the-shelf SMA cables with 1671J.
After the disk system trouble, we could not make the RTS running at the nominal state. A part of the troubleshoot FB1 was rebooted. But the we found that the GPS time was a year off from the current time
controls@fb1:/diskless/root/etc 0$ cat /proc/gps
controls@fb1:/diskless/root/etc 0$ date
Thu Sep 2 18:43:02 PDT 2021
controls@fb1:/diskless/root/etc 0$ timedatectl
Local time: Thu 2021-09-02 18:43:08 PDT
Universal time: Fri 2021-09-03 01:43:08 UTC
RTC time: Fri 2021-09-03 01:43:08
Time zone: America/Los_Angeles (PDT, -0700)
NTP enabled: no
NTP synchronized: yes
RTC in local TZ: no
DST active: yes
Last DST change: DST began at
Sun 2021-03-14 01:59:59 PST
Sun 2021-03-14 03:00:00 PDT
Next DST change: DST ends (the clock jumps one hour backwards) at
Sun 2021-11-07 01:59:59 PDT
Sun 2021-11-07 01:00:00 PST
Paco went through the process described in Jamie's elog [40m ELOG 16299] (except for the installation part) and it actually made the GPS time even strange
controls@fb1:~ 0$ cat /proc/gps
I decided to remove the gpstime module and then load it again. This made the gps time back to normal again.
controls@fb1:~ 0$ sudo modprobe -r gpstime
controls@fb1:~ 0$ cat /proc/gps
cat: /proc/gps: No such file or directory
controls@fb1:~ 1$ sudo modprobe gpstime
controls@fb1:~ 0$ cat /proc/gps
I gave some of the data analysts a look around because they asked and nothing was currently going on in the 40m. Nothing was changed.
We came this morning and noticed the FSS_FAST channel was moving very rapidly. Short inspection showed that MC3 watchdog got tripped. After reenabling the watchdog the issue was fixed and the MC is stable again.
There is a spike in the seismometers 8 hours ago and it was probably due to the 4.2 magnitude earthquake that happened in Malibu beach around that time.
This is a simple representation of the schematic:
gnd# |# Cw2# |# n23# |# Lw2# |# n22# |# Rw2 # | |\ # n2- - - C2 - n3 - - - - | \ # | | | | |4106>-- n5 - Rs -- no# iinput Rd L1 L2 R24 n6- | / | |# nin - | | | | | |/ | Rload # Cd n7 R22 gnd | | | # | | | | - - - R8 - - gnd # gnd R1 gnd R7 # | |# gnd gnd# ##
I chose the values of the components in a realistic way, that is using part available from Coilcraft or Digikey.
Using LISO I simulated the Tranfer Function and the noise of the circuit.
I'm attaching the results.
I'll post the 55MHz rfpd later.
oops, forgotten the third attachment...
here it is
# Resonant RF diode front end
I read a few datasheets of the C30642GH photodiode that we're going to use for the 11 and 55 MHz. Considering the values listed for the resistance and the capacitance in what they define "typical conditions" (that is, specific values of bias voltage and DC photocurrent) I fixed Rd=25Ohms and Cd=175pF.
Then I picked the tunable components in the circuit so that we could adjust for the variability of those parameters.
Finally with LISO I simulated transfer functions and noise curves for both the 11 and the 55MHz photodiodes.
I'm attaching the results and the LISO source files.
Use 10 Ohms for the resistance - I have never seen a diode with 25 Ohms.
p.s. PDFs can be joined together using the joinPDF command or a few command line options of 'gs'.
I spent some time trying to understand how touching the metal cage inside or bending the PCB board affected the photodiode response. It turned out that there was some weak soldering of one of the inductors.
Hartmut suggested a possible explanation for the way the electronics transfer function starts picking up at ~50MHz. He said that the 10KOhm resistance in series with the Test Input connector of the box might have some parasitic capacitance that at high frequency lowers the input impedance.
Although Hartmut also admitted that considering the high frequency at which the effect is observed, anything can be happening with the electronics inside of the box.
I upgraded the old REFL199 to the new REFL55.
To do that I had to replace the old photodiode inside, switching to a 2mm one.
Electronics and optical transfer functions, non normalized are shown in the attached plot.
The details about the modifications are contained in this dedicated wiki page (Upgrade_09 / RF System / Upgraded RF Photodiodes)
These are the dark noise spectrum that I measured on the 11MHz and 55MHz PD prototypes I modified.
The plots take into account the 50Ohm input impedance of the spectrum analyzer (that is, the nosie is divided by 2).
With an estimated transimpedance of about 300Ohm, I would expect to have 2-3nV/rtHz at all frequencies except for the resonant frequencies of each PD. At those resonances I would expect to have ~15nV/rtHz (cfr elog entry 2760).
I have to figure out what are the sources of such noises.
After adding an inductor L=100uH and a resistor R=10Ohm in parallel after the OP547A opamp that provide the bias for the photodiode of REFL11, the noise at low frequency that I had observed, was significantly reduced.
See this plot:
A closer inspection of the should at 11MHz in the noise spectrum, showed some harmonics on it, spaced with about 200KHz. Closing the RF cage and the box lid made them disappear. See next plot:
The full noise spectrum looks like this:
A big bump is present at ~275MHz. it could important if it also shows up on the shot noise spectrum.
From the measurements of the 11 MHz RFPD at 11Mhz I estimated a transimpedance of about 750 Ohms. (See attached plot.)
The fit shown in the plot is: Vn = Vdn + sqrt(2*e*Idc) ; Vn=noise; Vdn=darknoise; e=electron charge; Idc=dc photocurrent
The estimate from the fit is 3-4 times off from my analsys of the circuit and from any LISO simulation. Likely at RF the contributions of the parassitic components of each element make a big difference. I'm going to improve the LISO model to account for that.
The problem of the factor of 2 in the data turned out to be not a real one. Assuming that the dark noise at resonance is just Johnson's noise from the resonant circuit transimpedance underestimates the dark noise by 100%.
Putting my hands ahead, I know I could have taken more measurements around the 3dB point, but the 40m needs the PDs soon.
Something must be wrong.
1. Physical Unit is wrong for the second term of "Vn = Vdn + Sqrt(2 e Idc)"
2. Why does the fit go below the dark noise?
3. "Dark noise 4 +/- NaN nV/rtHz" I can not accept this fitting.
Also apparently the data points are not enough.
1) True. My bad. In my elog entry (but not in my fit code) I forgot the impedance Z= 750Ohm (as in the fit) of the resonant circuit in front of the square root: Vn = Vdn + Z * sqrt( 2 e Idc )
2) That is exactly the point I was raising! The measured dark noise at resonance is 2x what I expect.
I also admitted that the data points were few, especially around the 3dB point.
Today I'm going to repeat the measurement with a new setup that lets me tune the light intensity more finely.
All the details and data will be included in the wiki page (and so also the results for AS55). Here I just show the comparison of the transfer functions that I measured and that I modeled.
I applied an approximate calibration to the data so that all the measurements would refer to the transfer function of Vout / PD Photocurrent. Here's how they look like. (also the calibration will be explained in the wiki)
The ratio between the amplitude of the 55Mhz modulation over the 11MHz is ~ 90dB
The electronics TF doesn't provide a faithful reproduction of the optical response.
Here's another measurement of the noise of the REFL11 PD.
This time I made the fit constraining the Dark Noise. I realized that it didn't make much sense leaving it as a free coefficient: the dark noise is what it is.
Result: the transimpedance of REFL11at 11 MHz is about 4000 Ohm.
Data looks perfect ... but the fitting was wrong.
Vn = Vdn + Z * sqrt( 2 e Idc ) ==> WRONG!!!
Dark noise and shot noise are not correlated. You need to take a quadratic sum!!!
Vn^2 = Vdn^2 + Z^2 *(2 e Idc)
And I was confused whether you need 2 in the sqrt, or not. Can you explain it?
Note that you are looking at the raw RF output of the PD and not using the demodulated output...
Also you should be able to fit Vdn. You should put your dark noise measurement at 10nA or 100nA and then make the fitting.
Here's the (calibrated) transimpedance of the new REFL55 PD.
T(55.3) / T_(11.06) = 93 dB
After munching analytical models, simulations, measurements of photodiodes I think I got a better grasp of what we want from them, and how to get it. For instance I now know that we need a transimpedance of about 5000 V/A if we want them to be shot noise limited for ~mW of light power.
Adding 2-omega and f1/f2 notch filters complicates the issue, forcing to make trade-offs in the choice of the components (i.e., the Q of the notches)
Here's a better improved design of the 11Mhz PD.
This should be better. It should also have larger resonance width.
How much is the width?
The transfer function phase drops by 180 degrees in about 2MHz. Is that a good way to measure the width?
To measure the width of a resonance, the standard method is to state the center frequency and the Q. Use the definition of Q from the Wikipedia.
As far as how much phase is OK, you should use the method that we discussed - think about the full closed loop system and try to write down how many things are effected by there being a phase slope around the modulation frequency. You should be able to calculate how this effects the error signal, noise, the loop shape, etc. Then consider what this RFPD will be used for and come up with some requirements.
The measured transimpedance of the latest POY11 PD matches my model very well up to 100 MHz. But at about ~216MHz I have a resonance that I can't really explain.
The following is a simplified illustration of the resonant circuit:
Perhaps my model misses that resonance because it doesn't include stray capacitances.
While I was tinkering with it, i noticed a couple of things:
- the frequency of that oscillation changes by grasping with finger the last inductor of the circuit (the 55n above); that is adding inductance
- the RF probe of the scope clearly shows me the oscillation only after the 0.1u series capacitor
- adding a small capacitor in parallel to the feedback resistor of the output amplifier increases the frequency of the oscilaltion
I started putting together the components that are coint to go inside the frequency generation box. Here's how it looked like:
The single component are going to be mounted on a board that is going to sit on the bottom of the box.
I'm thinking whether to mount the components on an isolating board (like they did in GEO), or on an aluminum board.
I emailed Hartmut to know more details about his motivations on making that choice.
The choice of 100 Ohm for the isolating resistor was mainly empirical. I started with 10, then 20 and 50 until I got a sufficient suppression of the resonance. Even just 10Ohm suppressed the resonance by several tens of dB.
In that way the gain of the loop didn't change. Before that, I was also able to kill the resonance by just increasing the loop gain from 10 to 17. But, I didn't want to increase the closed-loop gain.
One thing that I tried, on Koji's suggestion, was to try to connect the RF output of the PD box to an RF amplifier to see whether shielding the output from the cable capacitance would make the resonance disappear: It did not work.
This idea was tried before by Dale in the ~1998 generation of PDs. Its OK for damping a resonance, but it has the unfortunate consequence of hurting the dynamic range of the opamp. The 100 Ohm resistor reduces the signal that can be put out to the output without saturating the 4107.
I still recommend that you move the notch away from the input of the 4107. Look at how the double notch solution has been implemented in the WFS heads.