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!
I spent some time trying to figure out how to get a record of the pointing of the input pointing tip-tilt (TT) channels.
Currently the TT pointing is done via the offset in the PIT/YAW filter banks, ie. C1:IOO-TT1_PIT_OFFSET, which is an EPICS record. I added these channels to the C0EDCU.ini, which (I'm pretty sure) specifies which EPICS channels are recorded to frames.
controls@pianosa:~ 0$ grep C1:IOO-TT /opt/rtcds/caltech/c1/chans/daq/C0EDCU.ini
I then confirmed that the data is being recorded:
controls@pianosa:~ 0$ FrChannels /frames/full/10466/C-R-1046657424-16.gwf | grep TT
The EPICS records for these channels *should* be recorded by autoburt, but Yuta noticed they were not:
controls@pianosa:~ 0$ grep -R C1:IOO-TT1_PIT_OFFSET /opt/rtcds/caltech/c1/burt/autoburt/snapshots/2013/Mar/6/
The autoburt log seems to indicate some sort of connection problem:
controls@pianosa:! 130$ grep C1:IOO-TT1_PIT_OFFSET /opt/rtcds/caltech/c1/burt/autoburt/logs/c1assepics.log
pv >C1:IOO-TT1_PIT_OFFSET< nreq=-1
pv >C1:IOO-TT1_PIT_OFFSET.HSV< nreq=-1
pv >C1:IOO-TT1_PIT_OFFSET.LSV< nreq=-1
pv >C1:IOO-TT1_PIT_OFFSET.HIGH< nreq=-1
pv >C1:IOO-TT1_PIT_OFFSET.LOW< nreq=-1
C1:IOO-TT1_PIT_OFFSET ... ca_search_and_connect() ... OK
C1:IOO-TT1_PIT_OFFSET.HSV ... ca_search_and_connect() ... OK
C1:IOO-TT1_PIT_OFFSET.LSV ... ca_search_and_connect() ... OK
C1:IOO-TT1_PIT_OFFSET.HIGH ... ca_search_and_connect() ... OK
C1:IOO-TT1_PIT_OFFSET.LOW ... ca_search_and_connect() ... OK
C1:IOO-TT1_PIT_OFFSET ... not connected so no ca_array_get_callback()
C1:IOO-TT1_PIT_OFFSET.HSV ... not connected so no ca_array_get_callback()
C1:IOO-TT1_PIT_OFFSET.LSV ... not connected so no ca_array_get_callback()
C1:IOO-TT1_PIT_OFFSET.HIGH ... not connected so no ca_array_get_callback()
C1:IOO-TT1_PIT_OFFSET.LOW ... not connected so no ca_array_get_callback()
This is in contrast to successfully recorded channels:
controls@pianosa:~ 0$ grep C1:LSC-DARM_OFFSET /opt/rtcds/caltech/c1/burt/autoburt/logs/c1lscepics.log
pv >C1:LSC-DARM_OFFSET< nreq=-1
pv >C1:LSC-DARM_OFFSET.HSV< nreq=-1
pv >C1:LSC-DARM_OFFSET.LSV< nreq=-1
pv >C1:LSC-DARM_OFFSET.HIGH< nreq=-1
pv >C1:LSC-DARM_OFFSET.LOW< nreq=-1
C1:LSC-DARM_OFFSET ... ca_search_and_connect() ... OK
C1:LSC-DARM_OFFSET.HSV ... ca_search_and_connect() ... OK
C1:LSC-DARM_OFFSET.LSV ... ca_search_and_connect() ... OK
C1:LSC-DARM_OFFSET.HIGH ... ca_search_and_connect() ... OK
C1:LSC-DARM_OFFSET.LOW ... ca_search_and_connect() ... OK
C1:LSC-DARM_OFFSET ... ca_array_get_callback() nreq 1 ... OK
C1:LSC-DARM_OFFSET.HSV ... ca_array_get_callback() nreq 1 ... OK
C1:LSC-DARM_OFFSET.LSV ... ca_array_get_callback() nreq 1 ... OK
C1:LSC-DARM_OFFSET.HIGH ... ca_array_get_callback() nreq 1 ... OK
C1:LSC-DARM_OFFSET.LOW ... ca_array_get_callback() nreq 1 ... OK
In fact all the records in the c1assepics log are showing the same "not connected so no ca_array_get_callback()" error. I don't know what the issue is. I have no problem reading the values from the command line, with e.g. ezcaread. So I'm perplexed.
If anyone has any idea why the c1ass EPICS records would fail to autoburt, let me know.
5) DTT wasn't working on rossa. Used the Date/Time GUI to reset the system time to match fb and then it stopped giving 'Test Timed Out'. Jamie check rossa ntpd.
ntp is now installed on all the workstations. I also added it to the /users/controls/workstation-setup.sh script
I restarted ntpd on op440m to solve a "synchronization error" that we were having in DTT. I also edited the config file (/etc/inet/ntp.conf) to remove the lines referring to rana as an ntp server; now only nodus is listed.
To do this:
log in as root
/usr/local/bin/ntpd -c /etc/inet/ntp.conf
I installed the following packages on rossa:
numpy, ipython, matplotlib, python-matplotlib
Adaptive filter outputs some non-zero signal in the OFF position
I turned "ON" one of them and c1lsc suspended, I've rebooted it and restarted models on c1lsc and c1sus.
Now it also outputs something non-zero though the first line of the adaptive code is "if(OFF) output=0.0; return;" May be another version of the code has been compiled.
Edit: Old version (~september) of the code and oaf model is running now. In the 2.1 code there was a link from src/epics/simLink to oaf code for each DOF. It seems that 2.5 version finds models and c codes in standard directories. I need to move working code to the proper directory.
Yes, things have changed. Please wait until I have things cleaned up before working on models. I'll explain what the new setup is.
Here are the issues that I found not quite accurate in the old oaf code:
1. There is no need to calculate the norm of the witness signal every time from zero:
norm += (*pBufAdapt) * (*pBufAdapt); // add to the norm
Every step the witness signal vector is the same except the first and last values
wit[i].norm += histAdpt[nCoeff]*histAdpt[nCoeff] - histAdpt*histAdpt;
This step will reduce the number of multiplications and summations from 3*M/k to 2*M/k, M - filter length, k - downsample ratio.
2. Old code filter corrects filter coefficients with a delay equal to k=downsample ratio (pretty big):
witness o o o o o o o o o o o o o o o o o o o o o
error o o o o o o o o o o o o o o o o o o o o o
We want the filter to work at green points and skip red points computing output and correcting coefficients at this time (downsample ratio in this example is 4). Old code
But LMS algorithm should correct coefficients according to the latest error. As we calculate output and correct coefficients before the latest error signal will be available, we should change the order:
This scheme is completely equivalent to the ordinary LMS algorithm, as now we correct coefficients according to the latest error signal and so do not add any delay.
3. So long soft start is probably not needed for the LMS filter, it makes the filter to converge longer
// modify adaptation gain for soft start
if( state.iWait < state.nFIR )
adaptGain = 0.0;
decayRate = 1.0; // clear FIR coeffs after reset
As far as I understand this is done to prevent the filter from huge coefficients variations in the beginning when norm is not calculated yet. Instead we can just introduce some small
epsilon = 10.0;
to prevent the filter from divergence in the beginning
delta = mu * error / (wit[i].norm + epsilon);
Though some soft start might be needed by not so long - it will take several minutes before the adaptation gain will take it's specified value.
Today I tried to make the lms filter to work online. I played around with the signals (GUR1_X and MC_F) to pre-whiten them and in the end the following configuration worked out:
1. mu = 0.03, tau = 1e-5, downsample=8, nCoeff = 4000, delay = 5 (sample-and-hold delay is not included in the new code, it should be added here!)
2. witness pass: AA32 = cheby1("LowPass", 4, 1, 32) AND 0.1:0
3. witness adaptation path: AA32 AND AI32 = cheby1("LowPass", 4, 1, 32) AND 0.1:0
4. error path: AA32 AND 0.1:0 AND anti_1Hz. Before I added anti_1Hz filter oaf did nothing. This filter tries to approximate the actuator transfer function. Note, it is not in the witness adaptation path. This is some sort of whitening.
5. correction path: AI32, gain = -1
Convergence time ~ 5 mins. The performance of the filter is far not perfect compared to the offline implementation. But it deals with a stack though.
(Johannes, Koji, Keerthana)
The PLL loop ensures that the frequency difference between the PSL laser and the AUX laser is equal to the frequency we provide to the Local Oscillator (LO) with the help of a Marconi. Only a small pick off part of both the AUX and PSL lasers are going to the PLL loop. The other part of both the lasers are going to the interferometer. Before entering into the optical fibre, the AUX laser passes through an AOM which changes its frequency by an amount of 80MHz. When the PLL is locked, the frequency coming out of the PLL will be equal to the frequency set up in the Marconi (fm). When it passes through AOM, the frequency becomes fdiff = fm ±80 MHz. If this frequency beam and the PSL laser beam is aligned properly, and if this frequency is equal to the product of an integer and the free spectral range of the cavity, this will resonate in the cavity. Then we expect to get a peak in the ETM transmission spectrum corresponding to the frequency we injected through the optical Fibre.
Through out the experiment we need to make sure that the PSL is locked. Thus, the signal detected by the photo detector when only PSL is resonating inside the cavity, act as a DC signal. Then we give a narrow scan to the Marconi. When fdiff = N*FSRy this condition is satisfied, we will observe a peak in the output. Here FSRy is the free spectral range of the cavity which is approximately equal to 3.893 MHz.
Yesterday afternoon, Johannes, Koji and myself tried to observe this peak. We aligned the cavity by observing the output signal from the AS100 photo detector. We made the alignment in such a way that the intensity output getting from this photo detector is maximum. We used a Spectrum analyser to see the output. After that we connected a photo detector to collect the YEND transmission signal from the ETM mirror. We used a lens to focus this directly to the photodetector. Then we connected this photodetector to the spectrum analyser, which was located near the AS table. We took a large cable to meet this purpose. But still the cable was not lengthy enough, so we joined it with another cable and finally connected it with the spectrum analyser. Then we gave a scan to the Marconi from 51 MHZ to 55 MHz. We repeated this experiment with a scan of 55 MHz to 59 MHz also. We repeated this a few times, but we were not able to see the peak.
We assume that this can be because of some issue with the alignment or it can be because of some issue with the photo detector we used. We would like to repeat this experiment and get the signal properly.
I am attaching a flow chart of the setup and also a picture of the mirrors and photo detector we inserted in the Y-End table.
I worked a bit on the PSL table today