Last night I tried searching for a beat note signal with two different PD trans impedance gains.
Although I didn't find a beat note signal.
- (1. trans impedance gain = 2400)
I started with a trans impedance resistance of R=2.4k, which is 10 times bigger resistance than the original.
The total PD gain should be about 960 [V/W] theoretically if we assume the responsibility of the PD is 0.4 [A/W].
Then I checked the bandwidth of the RFPD using Jenne laser.
The bandwidth was about 30MHz, which is 3 times narrower than the original. And it agrees with our expectation.
As Koji and I mentioned at the last weekly meeting, the cut off frequency of an RFPD follows inverse square root of the trans impedance resistance R.
where C is a capacitance of the photo diode. (See this)
I was expecting the signal level of -50 dBm / rtHz with a 23dB RF amplifier, assuming the line width of the signal is 10kHz.
- (2. trans impedance gain = 240)
I also tried it with the original trans impedance gain (see this entry).
R = 240 [Ohm]
G = 96 [V/W]
BW = 100 [MHz] (I didn't measure it in this time)
expected signal level = -70 dBm/rtHz
Still I didn't see any beat note signals..
Rana noticed that the sum on WFS2 was about 10 times smaller than that on WFS1. Though the beam appeared centered on the DC QPD screens it was not really true. When I went and checked the actual beam position it was landing on the metal enclosure of the WFS2 sensor and scattering back on to the diode.
I also checked the power levels of light landing on the sensors It was about 0.25mW in both cases. This needs further investigation since the power split at the beam spitter is like 0.25mW onto WFS1 and 0.45 towards WFS2. The lost 0,20 mW has to be traced and we have to be sure that it is not scattered around on the table.
It turns out there are no reasonable signal from the segment 1 on the IP_ANG QPD.
For right now I can still use it as a funny QPD, but I absolutely need somebody to check and fix it in a daytime.
IP_ANG is supposed to be acquired at c1auxey (east end), but actually it had been at c1auxex (south end).
So I fixed it by editing the db files (i.e. ETMXaux.db and ETMYaux.db). Now it seems working fine.
[Valery, kiwamu, Jenne, Suresh]
I first interchanged the two QPD's on the Y end table to see if the problem QPD related. Exchanging the units did not make any difference. The problem therefore had to be in the cables or the circuit boards in 1X4
We traced the signals pertaining to the IP_ANG QPD ( "Initial Pointing Beam") using Jay's wiring diagram (pages 2 and 5 of 7). We noted that while the signals were available on all Segments till the Monitors (Lemo) on 1X4-2-2A card, two of the lines did not reach the output of the cross connect 1X4-B8. We checked card to make sure that the signals were indeed reaching the back plane of the 1X4-2 chassis using a D990612 extension board. The card was found to be okay. We therefore suspected that the cable (CAB_1X4_?) going from the card to the cross connect 1X4-B8 was faulty. Indeed visual inspection showed that the crimping of the connector was poor and weight of the cable had put further strain on the crimping.
I changed the 64-pin connector on the 1X3-2-2A side of the cable.
When I connected everything back together the problems persisted. Namely the lines P1-1A (Segment 1 high) and P1-2C (Segment 2 Low) were floating They were not reaching points 2T and 3T respectively on the output of the cross connect.
I therefore replaced 1X4-B8 with a similar unit which I found in one of the shelves along the East (Y) arm.
I then checked with the StripTool to make sure that all the quadrants are showing similar response to a flashlight on the QPD. All Segments are working fine now. Currently the IR Initial Pointing beam reaches the QPD but is not centered on it.
I did not attempt to center it since the beam appeared to be clipped and may anyway require repositioning.
JD: We need to meditate on where this beam could be getting clipped. Suresh and I checked that it's not on the viewport on the beam's way out of the ETMY chamber by seeing that the beam is far away from the edges of the viewport, and also far away from the edges of the black beamtube between the viewport and the table. Suresh mentioned that the clipping nature of the IP_ANG beam sometimes goes away. I don't know if this is the same clipping that Kiwamu might be seeing with the main beam, or if this is separate clipping just with the IP beam, after it's been picked off. I suspect it's the same as what Kiwamu is seeing....maybe when we move PZT1, we clip on one of the MMT mirrors or PZT2?? If this is true, it's a total pain since we might have to vent if we can't steer around it.
No signal is transmitted from C1:GCV-SCX_ETMX_ALS (on c1gcv) to C1:GCV-SCX_ETMX_ALS (on c1scx)
I can't find RFM definition for ALS channels in c1rfm. Where are they???
As you've correctly noted, the source of the C1:GCV-SCX_ETMX_ALS channels is in the c1gcv model. The first 3 letters of the channel name indicate this (GCV).
The destination of this channel is c1scx, the 2nd 3 letters indicate this (SCX). If it passed through the c1rfm model, it would be written like C1:GCV-RFM_ETMX_ALS.
This particular channel doesn't pass through the c1rfm model, because the computers these two run on (c1ioo and c1scx) are directly connected via our old VMIC 5565 RFM cards, and don't need to pass through the c1sus computer. This is in contrast to all communications going to or from the c1lsc machine, since that is only connected the c1sus machine by the Dolphin RFM. The c1rfm also handles a bunch of RFM reads from the mode cleaner WFS, since each eats up 3-4 microseconds and I didn't want to slow the c1mcs model by 24 microseconds (and ~50 microseconds before the c1sus/c1scx computer switch).
So basically c1rfm is only used for LSC communications and for some RFM reads for local suspensions on c1sus.
As for the reason we have no transmission, that looks to be a problem on c1ioo's end. I'm also noticing that MCL is not updating on the MC2 suspension screen as well as no changes to MC PIT and YAW channels, which suggests we're not transmitting properly.
I rebooted the c1ioo machine and then did a burt restore of the c1ioo and c1gcv models. These are now up and running, and I'm seeing both MCL and ALS data being transmitted now.
Its possible that when we were working on the c1gfd (green frequency divider model) on c1ioo machine we disturbed the RFM communication somehow. Although what exactly, I'm not sure.
The /boot partition was filling up with old kernels. Nodus has automatic security updates turned on, so new kernels roll in and the old ones don't get removed.
I ran apt-get autoremove, which removed several old kernels. (apt is configured by default to keep two previous kernels around when autoremoving, so this isn't so risky)
Now: /dev/sda1 236M 94M 130M 42% /boot
/dev/sda1 236M 94M 130M 42% /boot
In principle, one should be able change a setting in /etc/apt/apt.conf.d/50unattended-upgrades that would do this cleanup automatically, but this mechanism has a bug whose fix hasn't propagated out yet (link). So, I've added a line to nodus' root crontab to autoremove once a week, Sunday morning.
controls@nodus|~ > df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/nodus2--vg-root 355G 69G 269G 21% /
udev 5.9G 4.0K 5.9G 1% /dev
tmpfs 1.2G 308K 1.2G 1% /run
none 5.0M 0 5.0M 0% /run/lock
none 5.9G 0 5.9G 0% /run/shm
/dev/sda1 236M 210M 14M 94% /boot
chiara:/home/cds 2.0T 1.5T 459G 77% /cvs/cds
fb:/frames 13T 11T 1.6T 88% /frames
Zach> Nodus seemed to be working fine again, and I was browsing the elog with no
Zach> problem. I tried making an entry, but when I started uploading a file it
Zach> became unresponsive. Tried SSHing, but I get no prompt after the welcome
Zach> blurb. ^C gives me some kind of tcsh prompt (">"), which only really
Zach> responds to ^D (logout). Don't know what else to do, but I assume someone
Zach> knows what's going on.
By gracefully rebooting nodus, the problem was solved.
It (">") actually was the tcsh prompt, but any commands with the shared or dynamic link libraries looked unfunctional.
I could use
to browse the directory tree. The main mounted file systems like /, /usr, /var, /cvs/cds/caltech looked fine.
I was afraid that the important library files were damaged.
in order to flush the file systems.
These should run even without the libraries as mount must properly work even before /usr is mounted.
They indeed did something to the system. Once I re-launch a new login shell, the prompt was still ">"
but now I could use most of the commands.
/, /usr, /var, /cvs/cds/caltech
I have rebooted by usual sudo-ing and now the services on nodus are back to the functional state again.
# nodus was working in the evening at around 9pm. I even made an e-log entry about that.
# So I like to assume this is not directly related to the linux1 incident. Something else could have happened.
I am guessing that the NFS file system hangup may have caused some machines to get into an awkward state. We may be best off doing a controlled power cycle of everything...
svn is back after starting apache on nodus.
mafalda is up now.
I found that the cable for mafalda (the sole red cable) had a broken latch.
The cable was about falling off from the switch. As a first-aid, I used this technique to put a new latch, and put it into the switch.
Now I can logged in it. I did not rebooted it.
The post OS migration admin for nodusa bout apache, elogd, svn, iptables, etc can be found in https://wiki-40m.ligo.caltech.edu/NodusUpgradeNov2017
Update: The svn dump from the old svn was done, and it was imported to the new svn repository structure. Now the svn command line and (simple) web interface is running. And "websvn" was also implemented.
I restored the nodus crontab (copied over from the Nov 17 backup of the same at /opt/rtcds/caltech/c1/scripts/crontab/crontab_nodus.20171117080001. There wasn't a crontab, so I made one using sudo crontab -e.
This crontab is supposed to execute some backup scripts, send pizza emails, check chiara disk usage, and backup the crontab itself.
I've commented out the backup of nodus' /etc and /export for now, while we get back to fully operational nodus (though we also have a backup of /cvs/cds/caltech/nodus_backup on the external LaCie drive), they can be re-enabled by un-commenting the appropriate lines in the crontab.
Update: The svn dump from the old svn was done, and it was imported to the new svn repository structure. Now the svn command line and (simple) web interface is running. "websvn" is not installed.
Confirmed that this crontab is running - the daily backup of the crontab seems to have successfully executed, and there is now a file crontab_nodus.ligo.caltech.edu.20171122080001 in the directory quoted below. The $HOSTNAME seems to be "nodus.ligo.caltech.edu" whereas it was just "nodus", so the file names are a bit longer now, but I guess that's fine...
We changed the password for controls on nodus this afternoon. We also zeroed out the authorized_keys file and then added back in the couple that we want in there for automatic backups / detchar.
Also did the recommended Ubuntu updates on there. Everything seems to be going OK so far. We think nothing on the interferometer side cares about the nodus password.
We also decided to dis-allow personal laptops on the new Martian router (to be installed soon).
nodus was rebooted by Alex at Fri Aug 14 13:53. I launched elogd.
./elogd -p 8080 -c /export/elog/elog-2.7.5/elogd.cfg -D
./elogd -p 8080 -c /export/elog/elog-2.7.5/elogd.cfg -D
It looks like Alex also rebooted all of the control room computers. Or something. The alarm handler and strip tool aren't running.....after I fix susvme2 (which was down when I got in earlier today), I'll figure out how to restart those.
Installed libmotif3 and libmotif4 on nodus so that we can run dataviewer on there.
Also, the lscsoft stuff wasn't installed for apt-get, so I did so following the instructions on the DASWG website:
Then I installed libmetaio1, libfftw3-3. Now, rather than complain about missing librarries, diaggui just silently dies.
Then I noticed that the awggui error message tells us to use 'ssh -Y' instead of 'ssh -X'. Using that I could run DTT on nodus from my office.
I just did remote apt-get update, apt-get upgrade, and then reboot on nodus. ELOG started up by itself.
nodus was hanging because it was trying to mount the cit40m account from rigel and rigel was not responding.
Neither I nor Yoichi can recall what the cit40m account does for us on nodus anymore and so I commented it out of the nodus /etc/vfstab.
nodus may still need a boot to make it pay attention. I was unable to do a 'umount' to get rid of the rigel parasite. But mainly I don't want anything in
the 40m to depend on the LIGO GC system if at all possible.
None of the links here seem to work. I forgot what the story is with our special apache redirect
The story is: we currently don't expose the whole /users/public_html folder. Instead, we are symlinking the folders from public_html to /export/home/ on nodus, which is where apache looks for things
So, I fixed the links on the Core Optics page by running:
controls@nodus|~ > ln -sfn /users/public_html/40m_phasemap /export/home/
I tried to follow these instructions today to make the Simulink Webview accessible:
controls@nodus|public_html > ln -sfn /users/public_html/FE /export/home/
But...I got a "403 Forbidden" message. What is the secret handshake to get this to work? And why have we added this extra step of security?
This link works for me: https://nodus.ligo.caltech.edu:30889/FE/c1als_slwebview.html. The problem with just /FE/ is that there is no index.html, and we have turned off automatic directory listings.
IIRC, this arrangement was due to the fact that authentication of some of the folders (maybe the wikis) was broken during the nodus upgrade, so there was sensitive information being publicly displayed. This setup gives us discretion over what gets exposed.
I suppose before directory listings were turned off we should have fixed the script to make an index.html, but that's how it goes with "up"-grades. How about re-allow directory listing so that our old links for webview work again?
EQ: https://nodus.ligo.caltech.edu:30889/FE is live
This was done by adding "Options +Indexes" to /etc/apache/sites-available/nodus
I've added a little more info about the apache configuration on the wiki: ApacheOnNodus
I made a coarse noise budget in order to decide our next actions for the X arm green locking.
So be careful, this is not an accurate noise budget !
Some data are just coming from rough estimations and some data are not well calibrated.
Assuming all the noise are not so terribly off from the true values, the noise at high frequency is limited by the dark noise of the PD or it already reaches to the IR inloop signal.
The noise at low frequency is dominated by the intensity noise from the transmitted green light although we thought it has been eliminated by the comparator.
In any case I will gradually make this noise budget more accurate by collecting some data and calibrating them.
According to the plot what we should do are :
* More accurate PD noise measurement
* More accurate shot noise estimation
* Searching for a cause of the small beat signal (see here) because a bigger beat signal lowers the PD noise.
* Investigation of the Intensity noise
Here I explain how I estimate the contribution from the differential noise shown in the plot on my last entry (#4376) .
According to the measurement done about a week ago, there is a broadband noise in the green beatnote path when both Green and IR are locked to the X arm.
The noise can be found on the first plot on this entry (#4352) drawn in purple. We call it differential noise.
However, remember, the thing we care is the noise appearing in the IR PDH port when the ALS standard configuration is applied (i.e. taking the beatnote and feeding it back to ETMX).
So we have to somehow convert the noise to that in terms of the ALS configuration.
In the ALS configuration, since the loop topology is slightly different from that when the differential noise was measured, we have to apply a transfer function to properly estimate the contribution.
(How to estimate)
It's not so difficult to calculate the contribution from the differential noise under some reasonable assumptions.
Let us assume that the MC servo and the end PDH servo have a higher UGF than the ALS, and assume their gains are sufficiently big.
Then those assumptions allow us to simplify the control loop to like the diagram below:
Since we saw the differential noise from the beatnote path, I inject the noise after the frequency comparison in this model.
Eventually the noise is going to propagate to the f_IR_PDH port by multiplying by G/(1+G), where G is the open loop transfer function of the ALS.
The plot below shows the open loop transfer function which I used and the resultant G/(1+G).
In the curve of G/(1+G), you can see there is a broad bump with the gain of more than 1, approximately from 20 Hz to 60 Hz.
Because of this bump, the resultant contribution from the differential noise at this region is now prominent as shown in the plot on the last entry (#4376).
I made a noise budget for the ALS noise measurement that I did a week ago (see #4352).
I am going to post some details about this plot later
It turned out that the dark noise from the beat PD and the shot noise on the beat PD was overestimated.
So I corrected them in the plot of the last noise budget (#4482).
Additionally I added the end laser error signal in the plot. Here is the latest plot.
The end laser error spectrum is big enough to cover most of the frequency range.
(although it was taken at a different time from the other curves.)
So I started fully characterizing the beat detection path.
As a part of the characterization works, I measured the spectra of the RFPD noise as well.
The noise is totally dominated by that of the RFPD (i.e. not by an RF amplifier).
I am going to check the noise curve by comparing with a LISO model (or a simple analytical model) in order to make sure the noise is reasonable.
The red curve represents the dark noise of the RFPD, which is amplified by a low noise amp, ZFL-1000LN.
The blue curve is a noise of only ZFL-1000LN with a 50 Ohm terminator at its input.
The last curve is noise of the network analyzer AG4395A itself.
It is clear that the noise is dominated by that of RFPD. It has a broad hill around 100MHz and a spike at 16MHz.
Gain of ZFL-1000LN = 25.5 dB (measured)
Applied voltage to ZFL-1000LN = +15.0 V
Bias voltage on PD = -150 V
New noise spectra of the green locking have been updated.
The plot below shows the in-loop noise spectra when the beat signal was fedback to ETMX.
The rms noise integrated from 0.1 Hz to 100 Hz went down to approximately 2 kHz.
The red curve was taken when the beat was controlled only by a combination of some poles sand zeros on the digital filter banks. The UGF was at 40Hz.
This curve is basically the same as that Koji took few weeks ago (see here). Apparently the rms was dominated by the peaks at 16 Hz and 3 Hz.
The blue curve was taken when the same filter plus two resonant gain filters (at 16.5 Hz and 3.15 Hz) were applied. The UGF was also at 40Hz.
Due to the resonant gain filter at 16.5 Hz, the phase margin became less, and it started oscillating at the UGF as shown in the plot.
Till RIN measurement noise eater is off on 2W laser. The inno 1W has no noise eater.
2010 power v current table is below.
Koji and Kevin measured the output power vs injection current for the Innolight 2W laser.
The threshold current is 0.75 A.
The following data was taken with the laser crystal temperature at 25.04ºC (dial setting: 0.12).
During the Y arm ALS I found that the noise of the AS55 demod signal was worse than that of POY11 in terms of the Y arm displacement.
There is a bump from 500 mHz to 100 Hz in the AS55 signal while POY11 didn't show such a structure in the spectrum.
The plot below is the noise spectra of the Y arm ALS. The arm length was stabilized by using the green beat-note fedback to ETMY.
In this measurement, POY11 and AS55 were served as out-of-loop sensors, and they were supposed to show the same noise spectra.
In the plot It is obvious that the AS55 curve is louder than the POY curve.
CC1 and CC2 are working again. Why did they start working again ?
Yesterday Koji was claiming that the rms monitor of ULSEN on ETMY didn't well go down.
Indeed something bad is happening on ULSEN of ETMY.
I guess it could be a loose connection.
(The unit of Y axis in the plot is not true. Don't believe it !)
The noisy fan belt on the roof of the control room was finally replaced on Friday, Jan 22 2016
Air condition maintenance is happening. It should be done by 10am
Our new janitor Francisco is started working in IFO room today.
The MET#1 particle counter was moved from CES wall at ITMX to PSL enclousure south west corner at 11am.
The HEPA filter speed at the Variac was turned down to 20V from 40
This counter pumps air for 1 minute in every 20 minutes. Soft foam in bags used to minimize this shaking as it is clamped.
Large film crews are working just out side the north west corner of the lab. They started around ~ 5:30am Do not plan on working late tonight.
ETMX sus damping restored.
C1:PSL-FSS_RMTEMP, C1:PSL-PMC_PMCTRANSPD and C1:PEM-count_temp channels are not reading since Friday
Glitches are gone. Rga scan is good
CYAN - cryo ON
BLACK - cryo OFF
BLUE - no crappy lens + mount
Our 4 ion pumps were closed off for a lomg time. I estmated their pressure to be around ~1 Torr. After talking with Koji we decided not to vent them.
It'd be still useful to wire their position sensors. But make sure we do not actuate the valves.
The cryo pump was regenerated to 1e-4 Torr about 2 years ago. It's pressure can be ~ 2 Torr with charcoal powder. It is a dirty system at room temperature.
Do not actuate VC1 and VC2, and keep its manual valve closed.
IF someone feels we should vent them for some reason, let us know here in the elog before Monday morning.
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.
Direct Form 2 is noisy in the first test. This is the one similar to Matt's in his presentation. Input signal was a sine wave at 1 Hz with small amplitude white noise x[n] = sin(2*pi*1*t[n]) + 1e-10 * random( [-1, 1] ). It was filtered with a notch filter: f=1Hz, Q=100, depth=210dB. SOS representation was calculated in Foton. Sampling frequency is 16kHz.
DF2 output noise level is the same if I change white noise amplitude while DF1, BQF, LNF can follow it. Time series show quantization noise of DF2. I've plotted coherence of the signals relative to DF1, because non of the signals will be coherent to it at low frequencies due to fft calculations.
In the second test the input was white noise x[n] = random( [-1, 1] ) It was filtered with a 2 order low-pass butterworth filter with cut-off frequency f = 0.25 Hz. SOS representation was calculated in Python. Sampling frequency is 16kHz.
In this test all implementations work fine. I guess dtt works with single precision and for that reason we see disturbance in coherence when we do the same test online.
If the problem is the precision in DTT, then why would the noise change when the corner frequency of the filter is changed?
And how about checking for filter noise in the situation we saw online? 4th order low pass at 1 Hz or 8 Hz.
If the problem is the precision in DTT, then why would the noise change when the corner frequency of the filter is changed?
This is because when we plot signals with sampling frequencies 2k and 16k with the same BW, we actually create psd/coherence using different numbers of points in FFT calculations as NFFT ~ fs/bw, fs-sampling frequency. So we secretly used 8 times more fft points for 16k signal then for 2k signal. Following plots demonstrate this effect. The first plot shows transfer function and coherence for filtering of 16k signal with butter('LowPass',4,8) and 2k signal with butter('LowPass',4,1) when BW=0.1. There is a disturbance in coherence for 2k signal below 2 Hz. Now let's take BW=0.8 and plot transfer function and coherence for 16k signal. We can see the same effect of coherence disturbance.
The similar effect takes place when we change the cut-off frequency. The following plots show transfer function and coherence of two pairs of 2kHz signals. 4 order butterworth low-pass filter was used. For the first pair cut-off frequency was 1 Hz, for the second 10 Hz. On the first plot BW=0.1 and there is a disturbance in coherence below 1 Hz. However on the second plot when BW=0.01, this effect is lost.
I guess my goal is to figure out when these effects come from fft calculations and when from digital filter noise.
Note from Stephen on more sensitive Baslers.
I've updated the scripts for the MC auto locking. Due to some permissions issues or general SVN messiness, most of the scripts in there were not saved anywhere and so I've overwritten what we had before.
After all of the electronics changes from Monday/Tuesday, the lock acquisition had to be changed a lot. The MC seems to catch on the HOM more often. So I lowered a bunch of the gains so that its less likely to hold the HOM locks.
A very nice feature of the Autolocker running on megatron is that the whole 'mcup' sequence now runs very fast and as soon as it catches the TEM00, it gets to the final state in less than 2 seconds.
I've also increased the amplitude of the MC2 tickle from 100 to 300 counts to move it through more fringes and to break the HOM locks more often. Using the 2009 MC2 Calibration of 6 nm/count, this is 1.8 microns-peak @ 0.03 Hz, which seems like a reasonable excitation.
Using this the MC has relocked several times, so its a good start. We'll have to work on tuning the settings to make things a little spicier as we move ahead.
That directory is still in a conflicted state and I leave it to Eric/Diego to figure out what's going on in there. Seems like more fallout from the nodus upgrade:
controls@chiara|MC > svn up
svn: REPORT of '/svn/!svn/vcc/default': Could not read chunk size: Secure connection truncated (https://nodus.ligo.caltech.edu:30889)
Oplevs and IP ANG are still centered. Why do the SRM and PRM move 5X more ? I could not check the sensing voltages because the computer failed.
AS and REFL are looking the same as last night.
ALL LOOKING GOOD!