40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 80 of 341  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  17047   Fri Jul 29 20:21:11 2022 KojiUpdatePSLFSSSlow/MCAutolocker issue (docker)

MCAutolocker/FSSSlow are not properly documented and not properly working.
Tidy up the script and documentation, or bring it back to megatron


I was aware that the FSSSlow was misbehaving since the shutdown upon the July power outage.
- FSS Slow servo did nothing even though the apparent settings in C1:PSL_SLOW screen looked fine and heart beat blinking
- Wanted to restart FSSSlow at megatron. Despite the login message showing how to do it, the system service does not exist anymore, because it was moved somewhere.
- Searched 40m wiki but found no info how to kill and restart it
- Found an elog. It was moved to docker on optimus ELOG 16480 . The restart procedure can only be found here. Please fix all the documentation inconsistency >> Anchal

According to this elog, the following commands need to be run for starting up MCAutolocker and FSSSlow on optimus:

cd /opt/rtcds/caltech/c1/Git/40m/scripts/MC
sudo docker-compose up -d

- Problem continues. Now FSSSlow is running but only when the IMC is locked. It does not stop even when the IMC lock is lost. How can we debug docker thing?
- This is minor but the MCAutolocker log (/opt/rtcds/caltech/c1/scripts/MC/logs/AutoLocker.log) is no longer updated even though MCAutolocker is running. Was it moved somewhere?

 

  17049   Sat Jul 30 10:38:12 2022 AnchalUpdatePSLFSSSlow/MCAutolocker issue (docker)

The FSSSlow script was not properly documented and it was not working, so I had to use one that I knew worked from CTN. This scripts lives in

/opt/rtcds/caltech/c1/Git/40m/scripts/PSL/FSS/PIDLocker.py

and uses a configuration file

/opt/rtcds/caltech/c1/Git/40m/scripts/PSL/FSS/PIDConfigFSS.yml

The script runs all the time inside docker container which keeps it running. The heart-beat blinker shows if the script is active or not, but it only starts working when C1:IOO-MC_LOCK is 1 and C1:PSL-FSS_SLOWLOOP is 1. The second channel is a button on C1PSL_SLOW screen to engage autolocker. It has to be turned on for FSS to work.

 


docker instructions:

The following message is displayed on login in optimus:

-------------------------------------------------------------------------
This computer runs four services as of Feb 18, 2022 for 40m lab. To check
status of these services, type
> sudo docker ps
For restarting a particular service, type:
> sudo docker restart container_name
where container name can be found from ps command above.
Fimilarly, to check status of a service, type:
> sudo docker logs container_name

In case, you have just rebooted the machine, to start these services do
following:
> cd /opt/rtcds/caltech/c1/Git/40m/softchansmodbus
> sudo docker-compose up -d
> cd /opt/rtcds/caltech/c1/Git/40m/scripts
> sudo docker-compose up -d

To stop the docker services completely, for example before a reboot, do
following:
> cd /opt/rtcds/caltech/c1/Git/40m/scripts
> sudo docker-compose down
> cd /opt/rtcds/caltech/c1/Git/40m/softchansmodbus
> sudo docker-compose down

This should remove all active containers from the computer.

To check IP address of running containers, type:
> sudo docker inspect -f '|| {{range.NetworkSettings.Networks}}{{.IPAddress}}{{end}}   ||   {{.Name}} ||' $(sudo docker ps -aq)

The softchansmodbus directory runs modbusEPICS docker image to host some
useful soft EPICS channels. The scripts directory runs pyep docker
image to run MC autolocker, PMC autolocker and FSS PID locker.
-------------------------------------------------------------------------

For checking log files of autolocker script, on optimus do:

sudo docker logs scritps_AL_MC_1

For checking log files of FSS PID loop, on optimus do:

sudo docker logs scripts_PID_

In the above commands, add < | tail -15> to just see the most recent 15 lines in the log file. change 15 to whatever number of lines you want to see from the end.

At any time, if you want to know how docker is running stuff, check out the /opt/rtcds/caltech/c1/Git/40m/scriptsdocker-compose.yml file for self-explanatory script usage.

I'll add some documentation on the wiki soon. That is indeed required and should have been done already.


Debugging scripts:

All scripts could be debugged by running them on rossa by directly using python command. You can stop the docker container on optimus using:

sudo docker stop container_name

and then run the file on rossa to check it's behavior. After debugging and fixing any issues, please commit the file to gitlab repo and go back to optimus and restart the docker container:

sudo docker restart container_name

I'll add this procedure to a wiki page as well.


Reverting back to systemd on megatron

The setup on megatron was not removed at all. All service files exist in same place and old scripts can be started in the old manner by doing following on megatron:

For FSSSlow:

sudo systemctl enable FSSSlow
sudo systemctl restart FSSSlow

For MC autolocker:

sudo systemctl enable MCautolocker
sudo systemctl restart MCautolocker

For diabling these services again, do:

sudo systemctl stop FSSSlow
sudo systemctl disable FSSSlow
sudo systemctl stop MCautolocker
sudo systemctl disable MCautolocker

Note that one should stop docker containers on optimus before starting these systemd services to avoid conflicting scripts running together.

I have added above instructions on megatron motd. So on loging into megatron, these updated instructions would come.

If someone wants to fix the old scripts and use systemd for managing those scripts, please do so but I won't be able to help in debugging those old scripts. The shell scripts are very complicated and beyond my knowledge and python scripts are lacking documentation.

I'm happy to help debug or extend the functionality of the new scripts that live in the git directory.

  17050   Sat Jul 30 12:48:18 2022 KojiUpdatePSLFSSSlow/MCAutolocker issue (docker)

> it only starts working when C1:IOO-MC_LOCK is 1 and C1:PSL-FSS_SLOWLOOP is 1.

- OK. Your new MCAutolocker does not reflect the lock status to C1:IOO-MC_LOCK. This causes FSS Slow to go crazy when the IMC is not locked. Can you fix that?

- So C1PSL_SLOW.adl screen, which spawns by the "SLOW Servo" button on the FSS screen, has no effect on the FSS SLOW servo anymore. It is obsolete. At least the screen (or the link to the screen) should be removed. (Work on it once you are back.)

- Also, please make a wiki page and copy the description on the previous page.

  17057   Thu Aug 4 11:28:22 2022 AnchalUpdatePSLFSSSlow/MCAutolocker issue (docker)

Added C1:IOO-MC_LOCK to ALConfigMC.yml which solved the isse with FSS Slow. We should tune the FSS Slow Servo PID coefficients for a better performance.

the C1PSL_SLOW.adl screen is not obsolete. It can be used to change the PID coefficients, engage/disengage the PID loop, monitor the PID script blinker, and monitor FAST actuator value C1:PSL-FSS_FAST. the functionality of this screen has not changed from before.

I've also added a wiki page for scripts documentation.

  17065   Mon Aug 8 14:47:10 2022 ranaUpdatePSLFSSSlow/MCAutolocker issue (docker)

can't we just go back to the old python script that was working for many years, and tested? I imagine that as soon as someone besides you tries to debug the docker setup, this is what will happen.

Quote:

Added C1:IOO-MC_LOCK to ALConfigMC.yml which solved the isse with FSS Slow. We should tune the FSS Slow Servo PID coefficients for a better performance.

the C1PSL_SLOW.adl screen is not obsolete. It can be used to change the PID coefficients, engage/disengage the PID loop, monitor the PID script blinker, and monitor FAST actuator value C1:PSL-FSS_FAST. the functionality of this screen has not changed from before.

I've also added a wiki page for scripts documentation.

 

  10315   Fri Aug 1 00:51:07 2014 KojiUpdatePSLFSSSlowServo update

FSS Slow set point to be zero


op340m:FSS>cat FSSSlowServo
#!/usr/bin/perl -w

# PID Servo for PSL-FSS (Slow)
# Tobin Fricke 2007-01-09

use strict;
#use Scalar::Util qw(looks_like_number);

sub looks_like_number {
    return ($_[0] =~ /^-?\d+\.?\d*$/);  #FIXME
}

use EpicsTools;

# Parameters
my $process  = 'C1:PSL-FSS_FAST';
my $actuator = 'C1:PSL-FSS_SLOWDC';
#my $setpoint = 5.5;
my $setpoint = 0;
my $blinkystatus = 0;
 

op340m:scripts>/opt/rtcds/caltech/c1/scripts/PSL/FSS/FSSSlowServo > /cvs/cds/caltech/logs/scripts/FSSslow.cronlog &

  633   Thu Jul 3 16:57:23 2008 JohnSummaryGeneralFSS_RMTEMP
The FSS room temp alarm has been beeping a lot recently. I altered the FSS_RMTEMP alarm levels using the
same method as Rana.

The alarm is still souding so, at least by my calculations, it must be colder than usual.
Attachment 1: FSStime.png
FSStime.png
Attachment 2: FSSalarm.png
FSSalarm.png
  12992   Mon May 15 19:21:04 2017 KojiUpdateComputer Scripts / ProgramsFSSslow / MCautolocker restarted

It seems that FSS slow servo stopped working.

I found that megatron was restarted (by Rana, to finish an apt-get upgrade) on ~18:47 PDT today.

controls@megatron|~> last -5
controls pts/0        192.168.113.216  Mon May 15 19:15   still logged in   
controls pts/0        192.168.113.216  Mon May 15 19:14 - 19:15  (00:01)    
reboot   system boot  3.2.0-126-generi Mon May 15 18:50 - 19:19  (00:29)    
controls pts/0        192.168.113.200  Mon May 15 18:43 - down   (00:04)    
controls pts/0        192.168.113.200  Mon May 15 15:25 - 17:38  (02:12)


FSSslow / MCautolocker were restarted on megatron.

  13820   Mon May 7 11:46:07 2018 gautamUpdatePEMFW parameter update

As part of investigation into this issue, Jonathan Hanks pointed out that the "minute trends" being recorded by our system were actually only being recorded every 120 seconds (a.k.a. 2 minutes). He had fixed the appropriate line in the parameter file, but had not restarted the FW processes. I had restarted it on Friday. (but failed to elog it !) no

To check if this made any difference, I pulled 1 hour of "minute trend" data for the PSL table temperature channel from ~1 hour ago, and compared the number of datapoints against a 1 hour minute trend time series from 2 May. I've put the display with # of datapoints (for an identical length of time) from before [left] and after [right] the restart next to the plots in Attachment #1. Seems like we are getting minute trends written every 60 seconds now, as it should be yes.

The unavailability of trends from nodus is a separate issue for which JH has suggested another fix, to be elogged separately.

Quote:

for whatever reason, I am unable to get minute or second trends from nodus for any channels (IMC, PEM, etc) since the reboot. has there been some more recent FB failure or is this still a bug since last years FB catastrophe?

Attachment 1: FWreboot.png
FWreboot.png
  8012   Wed Feb 6 15:20:55 2013 yutaSummaryGeneralFWHM was wrong

I have to blame Jamie for putting extra 2 randomly.
Measured PRM-PR2 cavity finesse was actually 108 +/- 3 (even if you use digital system to get data).

Lorentzian fit:
  Lorentzian function is;

f(x;x0,gamma,A) = A * gamma**2/((x-x0)**2+gamma**2)

  where x0 is the location of the peak, gamma is HWHM, and A is the peak height.
  Lorentzian fitting function in my original code (/users/yuta/scripts/modescanresults/analyzemodescan.py) was

fitFunc = lambda p,x,m: (m-p[2])*p[0]**4/(4*(x-p[1])**2+p[0]**4)+p[2]

  In this function, p[0] is sqrt(FWHM), not sqrt(HWHM). I doubled gamma to make it FWHM and squared it because they should be positive.
  During Jamie's modification of my code, he doubled p[0]**2 to get FWHM, which is wrong (/users/jrollins/modescan/modescan.py).

  I should have commented that p[0] is sqrt(FWHM).

Redoing the analysis:
  1. I pulled 2 out, and modified Jamie's modescan.py so that you can name each peak with peakdistinguish=True option. I also modified fitpeak function so that it throws away "peaks" which don't look like a peak.

  2. If you run /users/yuta/PRCmodescan/run.py and name each peak, you will get peaks.csv which includes peak position, FWHM, and the type of the peak;

0.065017,0.001458,l
0.070446,0.001463,3
0.075940,0.001509,2
0.081552,0.001526,1
0.087273,0.001565,0
0.112027,0.001911,u
0.278660,0.002211,u
0.306486,0.001658,0
0.312480,0.001576,1
0.313626,2.507910,
0.318486,0.001626,2
0.319730,2.633097,
0.324801,0.001739,3
0.331848,0.001922,l
0.527509,0.001603,l
0.533231,0.001445,3
0.538648,0.001488,2
0.544081,0.001455,1
0.549517,0.001498,0
0.551725,2.422759,
0.570972,0.001346,u


  3. /users/yuta/PRCmodescan/calcmodescanresults.py reads peaks.csv and tells you the results;

Time between TEM00 and sideband  0.0239435  pm  0.00115999887452  sec
Calibration factor is  462.167602898  pm  22.3907907867  MHz/sec
FSR is  78.4797010471  MHz
FWHM is  0.729828720682  pm  0.0174145743828  MHz
TMS is  2.64718671684  pm  0.0538858477824  MHz
Finesse is  107.53166986  pm  2.5658325169
Cavity g-factor is  0.994390582331  pm  0.000228155661075
Cavity g-factor is  0.988812630228  pm  0.000453751681357   (Edited by YM; see elog #8056)
RoC of PR2 is  -187.384503001  pm  4.26100999578  m (assuming PRM RoC= 122.1  m)
RoC of PRM is  217.915890722  pm  5.65451518991  m (assuming PR2 RoC= -600  m)

  6772   Wed Jun 6 22:04:19 2012 JamieUpdateComputersFailed attempt to get pianosa to support dual monitors

I've spent an inordinate amount of time trying to figure out how to get pianosa to support dual monitors.  It apparently has some special nvidia graphics that are not well supported in Ubuntu (10.04 at least).  I've tried installing a newer kernel (3.0.0) and installing the special nvidia compile-from-source Ubuntu packages, but nothing is working.  And now unfortunately he's not giving me any video at all.  I'm sick of this today, so I'll try again tomorrow.

In the future we should avoid these bullshit nvidia cards like the plague.

  6773   Wed Jun 6 22:23:53 2012 JamieUpdateComputersFailed attempt to get pianosa to support dual monitors

I managed to get pianosa working again with just a single monitor.  I'm done trying to configure it for dual, though.

  5601   Mon Oct 3 14:05:41 2011 JenneUpdateSUSFailing to set SUS summary screen values

I assume it's because the burt restore didn't work for the SUS summary screen, but all of the values for the ifo suspensions (not the MCs...they're okay) are red. 

I am trying to run Rana's setSensors.py script, but am failing.  Any inspiration would be appreciated:

rosalba:SUS_SUMMARY>./setSensors.py 1001708529 500 .1 .25
['./setSensors.py', '1001708529', '500', '.1', '.25']
/cvs/cds/caltech/apps/linux64/python/lib64/python2.4/site-packages/nds/__init__.py:28: RuntimeWarning: No protocol specified, attempting protocol nds_v2
  super(daq, self).__init__(host, port)
Connecting NDS2 .... authenticate done
Traceback (most recent call last):
  File "./setSensors.py", line 81, in ?
    mean = acquire(x)
  File "./setSensors.py", line 73, in acquire
    daq.request_channel(chans[x])
Boost.Python.ArgumentError: Python argument types in
    daq.request_channel(daq, str)
did not match C++ signature:
    request_channel(_daq_t {lvalue}, daq_channel_t*)

I'm not exactly sure what the problem is.  Line 73, looks like it should have 2 arguments in the daq.request_channel, but even if I put in the "daq" variable (which is set a few lines above), I get the exact same error.  So...something else is wrong.  Ideas from someone who "speaks" python??

  5604   Mon Oct 3 17:27:23 2011 JenneUpdateSUSFailing to set SUS summary screen values

Quote:

I am trying to run Rana's setSensors.py script, but am failing.  Any inspiration would be appreciated:

rosalba:SUS_SUMMARY>./setSensors.py 1001708529 500 .1 .25
['./setSensors.py', '1001708529', '500', '.1', '.25']
/cvs/cds/caltech/apps/linux64/python/lib64/python2.4/site-packages/nds/__init__.py:28: RuntimeWarning: No protocol specified, attempting protocol nds_v2
  super(daq, self).__init__(host, port)
Connecting NDS2 .... authenticate done
Traceback (most recent call last):
  File "./setSensors.py", line 81, in ?
    mean = acquire(x)
  File "./setSensors.py", line 73, in acquire
    daq.request_channel(chans[x])
Boost.Python.ArgumentError: Python argument types in
    daq.request_channel(daq, str)
did not match C++ signature:
    request_channel(_daq_t {lvalue}, daq_channel_t*)

I'm not exactly sure what the problem is.  Line 73, looks like it should have 2 arguments in the daq.request_channel, but even if I put in the "daq" variable (which is set a few lines above), I get the exact same error.  So...something else is wrong.  Ideas from someone who "speaks" python??

 My guess is that this has something to do with the NDS client version you're using.  Try running the script on a machine where pynds and nds-client are known to be compatible, like pianosa.

  5674   Sun Oct 16 05:35:18 2011 ranaUpdateComputer Scripts / ProgramsFailing to set SUS summary screen values

Quote:

Quote:

I am trying to run Rana's setSensors.py script, but am failing.  Any inspiration would be appreciated:

rosalba:SUS_SUMMARY>./setSensors.py 1001708529 500 .1 .25
['./setSensors.py', '1001708529', '500', '.1', '.25']
/cvs/cds/caltech/apps/linux64/python/lib64/python2.4/site-packages/nds/__init__.py:28: RuntimeWarning: No protocol specified, attempting protocol nds_v2
  super(daq, self).__init__(host, port)
Connecting NDS2 .... authenticate done
Traceback (most recent call last):
  File "./setSensors.py", line 81, in ?
    mean = acquire(x)
  File "./setSensors.py", line 73, in acquire
    daq.request_channel(chans[x])
Boost.Python.ArgumentError: Python argument types in
    daq.request_channel(daq, str)
did not match C++ signature:
    request_channel(_daq_t {lvalue}, daq_channel_t*)

I'm not exactly sure what the problem is.  Line 73, looks like it should have 2 arguments in the daq.request_channel, but even if I put in the "daq" variable (which is set a few lines above), I get the exact same error.  So...something else is wrong.  Ideas from someone who "speaks" python??

 My guess is that this has something to do with the NDS client version you're using.  Try running the script on a machine where pynds and nds-client are known to be compatible, like pianosa.

 Doesn't work on pianosa either. Has someone changed the python environment?

pianosa:SUS_SUMMARY 0> ./setSensors.py 1000123215 600 0.1 0.25
Traceback (most recent call last):
  File "./setSensors.py", line 2, in <module>
    import nds
ImportError: No module named nds

  2918   Wed May 12 03:56:54 2010 KojiUpdateIOOFaraday aligned

Zach and Koji

The old small MMT was removed and wrapped by Al foils.

The steering mirror IM2-IM4 were displaced and aligned.

The Faraday isolator block is moved and aligned.

The MC is realigned and resonatng TEM-00.

Now the MC has slightly miscentered beam on the mirrors owing to change of the stack leveling.
OSEMs are also in a strange state. We should check this later.

  9302   Mon Oct 28 12:53:23 2013 JenneUpdateCDSFarfalla and Asia added to Host Table in Wiki

Quote:

I have updated the hostable on linux1 to give farfalla the 230 IP address and let 'asia' keep 225.

 Neither of these computers were listed in the Martian Host Table in the wiki, so I put them on there.  It's handy to keep this updated, so that we know what IP addresses are available.

  3674   Thu Oct 7 17:53:07 2010 yutaUpdateComputersFarfalla with Firefox, fixed

(Kiwamu, Yuta)

Symptom:
 Farfalla(Acer Aspire one KAV60 netbook) couldn't run Firefox and returned the following error:
  Error: platform version '1.9.2.8' is not compatible with
  minVersion >= 1.9.2.9
  maxVersion <= 1.9.2.9

What we did:
1. Added the following line to ~/.cshrc.
  alias firefox "/usr/lib/firefox-3.6/firefox"
2. Made a cool launcher for firefox.

Result:
 Farfalla can fly into the web with Firefox now.

Notes:

 Even if it was then before, bash could run firefox. tsch couldn't.
 The command firefox was /cvs/cds/caltech/apps/linux/bin/firefox for tsch, because of the source /cvs/cds/caltech/cshrc.40m.
 I did this to zita which had the same symptom, too.

Next work:

 Farfalla wakes up on the wrong side of the bed. This has to be fixed.

  15209   Thu Feb 13 01:47:39 2020 gautamUpdateALSFast ALS - delay line prep

A few years ago, Koji and I setup a delay line phase shifter, which can be used to impart a (switchable) delay to a signal path. Since we talked about reviving the fast (= high bandwidth) ALS control scheme at the meeting, I reminded myself of the infrastructure available.

  • Schematic
  • Comprehensive note on theory of operation / performance.
  • Past elog threads - #11603 and #11604.
  • Attachment #1 - my modification to the ALS screen to add a slider that controls the channel C1:LSC-BO_1_0_SET. The label is a bit misleading for now - elog11604 tells you the conversion between this slider value and the actual delay in nanoseconds, but I couldn't get a soft channel set up that correctly FLNKed to this record. In the process of trying to do so, I edited the C1_ISC-AUX_ALS.db file, and also restarted the modbus and latch processes on c1iscaux a few times.
  • Attachment #2 - frequency dependent loss for some representative delays. At ~200 MHz, I find the measured loss to be > 8dB, which is ~2dB more than what the D. Sigg note tells me to expect. This is rather a lot of loss, but I guess it's okay. Measurement cable loss was calibrated out with the AG4395A.
  • Attachment #3 - confirmation of constantness of delay as a function of frequency, for some representative delays. The "undelayed" setting corresponds to a fixed delay of ~4 nsec, which is consistent with what the D. Sigg note tells me to expect. Once again, I calibrated out the delay of the measurement setup using the AG4395A.

For a beat note in the regime 10-100 MHz, we should have plenty of range in this module to add a delay such that we zero one quadrature of the ALS DFD output (for a linear error signal). 

I then proceeded to connect the single-ended front panel BNC corresponding to the ALS_X_I DFD channel to the IN2 input of the CM board (this would be what we use for high bandwidth ALS feedback). The conventional ALS system uses the differential output from a rear-panel D-sub, so in principle, both systems could run in parallel. I confirmed that I could see a signal when the IN2 path on the CM board was engaged (monitored using ndscope at the CM_Slow output), and that this signal stabilized when the green laser was locked to the X-arm length, which itself was slaved to the PSL frequency using the usual POX locking scheme. I have not yet routed the LO leg of the ALS_X beat through the delay line phase shifter - see next elog for details.

Update about the ALS MEDM screen slider: the trick was to change the OMSL field of the C1:LSC-BO_1_0 channel to "closed_loop" instead of "supervisory". Once this is done, the DOL value of the same channel can be set to the soft channel C1:ALS-DelayCalc, which sets the 16 bit binary string that controls the delay. Because arbitrary delays are not possible, I think it's more natural for the user to interact with this 16-bit binary string rather than the actual delay itself. So the MEDM screen has been slightly modified from what is shown in Attachment #1.

Attachment 1: delaySlider.png
delaySlider.png
Attachment 2: delayLineLosses.pdf
delayLineLosses.pdf
Attachment 3: delayLineCal.pdf
delayLineCal.pdf
  15212   Fri Feb 14 00:53:50 2020 gautamUpdateALSFast ALS - more setup

In the process of setting up some cabling at 1Y2, I must've bumped a cable to the c1lsc expansion chassis. Anyways, the c1lsc models crashed. I ran the reboot script around 530pm PDT. Usual locking behavior was recovered after this. The work at 1Y2 was:

  • Ran a cable from X Beat power splitter ("LO" leg of the analog delay line) to variable delay line. 
  • Ran cable from delay line to demodulator's LO input.
  • Set up the SR785 for some CM board TF measurements.

The IN2 to CM board was already connected to I single ended output of the ALS X demodulator. The ~100 Hz UGF digital locking using the CM_SLOW path is straightforward but I didn't have any success with the AO path tonight. I wonder how high BW this lock can be made without injecting a ton of noise into the IMC loop, given that the EX uPDH only has ~ 10 kHz UGF.

Attachment #1 shows the spectra of the ALS signal 

  • The two "CM Slow" traces are the digitized "SLOW" output of the common mode board, whose IN2 is connected to the demodulated I output of the analog delay line.
  • The delay in the LO line of the analog delay line is adjusted to zero the DC value of this signal to best effort.
  • These spectra are measured with the arm cavities POX/POY locked, and the EX laser locked to the arm cavity using the end PDH box.
  • I simultaneously monitor the output of the digital phase tracker servo, and scale the CM Slow signal such that the spectra line up. The scaling factor required was to multiply the CM_SLOW signal x10 (CM board IN2 gain was set to +6dB, to account for the x2 gain in going from single ended to differential inside the ALS demodulator box).
  • One puzzline feature is why switching on the ADC whitening makes the ALS spectrum noisier (even though it clearly changes the digitization noise floor). There is a peak that appears at ~ 8 kHz with the whitening on, and it may also be downconverted noise from some peak at higher frequencies I guess (if the AA isn't sharp enough). 

Attachment #2 is an OLTF measurement.

  • In the blue trace, the arm length is controlled by using the CM Slow signal as an error signal, applying feedback to IMC length via MC2.
  • In the red trace, I turned the digital MC2 violin notches off, and added upped the IMC IN2 gain to -12 dB (AO gain slider = 0dB).
  • This was as high as I could go before the PC drive RMS began to go crazy.
  • But still, there isn't any significant phase advance.
  • It is possible I need to tack on a low-pass filter to prevent noise injection at higher frequencies...
Attachment 1: CMSlow_ALSnoise.pdf
CMSlow_ALSnoise.pdf
Attachment 2: OLTFmeas.pdf
OLTFmeas.pdf
  11686   Tue Oct 13 16:28:21 2015 ericqUpdateLSCFast ALS pomona

I've made a cascaded passive 2-pole pomona box for fast ALS use, using LISO to check that it'll give the right shape when hooked up to the CM board's input stage. 

First stage is a 133Ohm + 10uF cap for ~120Hz LP, second is 1.15kOhm + 47nF cap for ~3.8kHz LP. The DC gain is ~0.75, which is much better than what I was doing before. The second stage would normally make a 2.9kHz LPF on its own, but the loading of the input stage moves the corner up. 

It seems the 133 Ohm resistor is a reasonable load on the output AD829 of the ALS demod board (short-circuit output current of 32mA and a series output resistor of 499Ohm). To be able to use the digitized ALSX I and the lowpassed analog version simultaneously, I had to buffer the signal with a SR560 before the pomona box, otherwise the signals looked distorted. This isn't a good long-term solution. Maybe I can used the further-buffered differential output to drive the LPF+CM board. 

The LISO files used to model the filter and CM board input stage, and fit the pole frequencies are attached. 

I made some attempts to get the AO path going today, but I suspect this daytime noise is just too much; the PC drive seems too irritable

Attachment 1: liso_lp.zip
Attachment 2: 2LPfit.pdf
2LPfit.pdf
  11658   Fri Oct 2 03:29:16 2015 ericqUpdateLSCFast ALS progress - AO path crossed over, but no high BW

I've been using an SR560 to experiment with differnent pole frequencies, to try and cancel the mystery zero. It's after the ALS demod board, before the pomona LPF with a gain of five. 

A pole frequency of 3kHz seems to recover sensible loop shapes. I've been able to crossover the AO path to make a nice long phase bubble which isn't the prettiest, but seems workable.

Getting to this point is now almost entirely scripted and repeatable; one just has to make sure that the ALS beat has the correct sign and adjust the delay line length. Most frustratingly, due to the dependence of the ALS gain on beat frequency / magnitude / delay, which can all vary on the order of a few dB, the AO gain settings to get to the crossed over point are not always the same, so at the end it's a lot of small steps and frequent loop measurements. 

The FSS crossover and overall IMC loop gain have to be pretty actively managed too. It's all too easy to drive the pockel's cell crazy. And if it's going crazy on its own anyways, there's no hope in trying to pile ALS sensing noise on top of it... It would really help in this effort to fix the whole PC situation up. 

Unfortunately, lock is lost when increasing the overall gain on the common mode board even by 1dB.angry We've seen in the single arm tests, that the gain settings have an appreciable difference in offset between them. Maybe this step is more than what the loop can handle? Or maybe it's the voltage glitches... Maybe some gain reallocation can put me on a region of the slider that glitches less.

In terms of the mystery plant features, I figure I'd like to take the analog TF of AO control signal to, say, AS55, and see what may or may not be there. I just haven't done this tonight since it would involve recabling the analyzer, and I still need frequent loop measurements to get to the crossed over state. Having ITMY misaligned and using the digital AS55Q spectrum as an out of loop monitor has been very helpful. 

Attachment 1: crossedover.pdf
crossedover.pdf
  11620   Fri Sep 18 13:33:17 2015 ericqUpdateLSCFast ALS troubles - Noise at 36kHz

To get around the problems between the pomona LPF and low CM board input impedance, I've placed the LPF at the CM board fast output. This won't work as a permanent solution, since we only want to lowpass the ALS signal, but it should be fine for a single arm test. 

However, I kept getting blown out of lock when turning up the AO gain, but well before I really expect any real action from the fast path. Looking at the OLTF, I was seeing some large spike at ~36kHz nearing 0dB loop gain with unstable phase. This prompted me to look at the ALS error signal out to higher bandwidth with the SR785; before I only ever looked at it through the digital system. 

So, with the X arm locked via POX11 I, and ITMY misaligned to use AS55 as an out of loop sensor, I measured the spectrum of the I ouput of the ALS X demod board (which was set to be near a zero crossing via the delay line), and the Q Mon of the AS55 demod board. 

Both ALS and AS55 show a sharp line at around 36.5kHz, so something is really happening in the IFO at this frequency. Koji might have seen an indication of this back in March.

What's going on here? And what would be different about PRFPMI that wouldn't have made this a problem for locking?

Attachment 1: IRlock_noises.pdf
IRlock_noises.pdf
  11621   Fri Sep 18 16:08:41 2015 ericqUpdateLSCFast ALS troubles - Noise at 36kHz

 I looked at REFL11 and REFL55 during PRMI lock - the line is there.

In fact, it is even visible in REFL11 I from a single bounce off of the PRM (ITMs misaligned).

This led me to look at the IMC error point (via the OUT2 on the servo board, no compensation for the input gain). Also there!

Attachment 1: PRMIlock_REFLspectra.pdf
PRMIlock_REFLspectra.pdf
Attachment 2: IMCspectrum.pdf
IMCspectrum.pdf
  11622   Fri Sep 18 19:15:35 2015 ranaUpdateLSCFast ALS troubles - Noise at 36kHz

One the Wiki (https://wiki-40m.ligo.caltech.edu/40mHomePage), we have a Mech Resonance page for mechanical frequencies and a PEM page where we want to list the sources of all of our environmental lines. So please put in an entry when you find out what's at this frequency. This reminds me that I need to upload my MC2 COMSOL eigenmode analysis.

  11648   Tue Sep 29 16:52:49 2015 ericqUpdateLSCFast ALS troubles - unknown zero

Fast ALS control continues to elude me. 

I fixed my LPF to take the input impedance of the CM board input into account; this unfortunately results in about -12dB DC gain of the ALS signal due to voltage-divider-y things, but by my estimation, this still puts the DFD noise above the input-referred voltage noise of the input AD829 on the CM board, so it'll do for now. The 120Hz pole shows up as expected when comparing the usual digital channels and the CM_SLOW output, and is digitally compensated with a zero at 120Hz (with a digital pole at 5k so nothing blows up). 

However, there seems to be some zero in the analog path somewhere that spoils the loop shape for the AO path. Here's a measurement of the X arm OLG from 10-100kHz, when the digital control is happening with ~100Hz UGF via ALS X I -> CM IN2 -> CM_SLOW -> LSC_CARM -> ETMX, and there is some AO action via ALS X I -> CM IN2 -> IMC IN2

The peak is recognizable as the gain peaking in the IMC servo (and changes predictably with changes to the IMC crossover and loop gains), which is expected. However, one can see that the magnitude is roughly flat before the peak, and the phase is around 0. With the 1/f LPF, we should see some downward slope and phase starting around -90. 

Thus, there must be some zero in the fast or common path, maybe at a few kHz where the digital loop wouldn't really see its effect. I'm not sure what it could be at this point in time.

One thought I had is that I never really checked the TF of DFD response to frequency modulation of the RF beat. I used an SR785 to drive the external FM input of a Fluke 1061A synthesizer, and saw it to be totally flat from 1-100kHz with carriers from 30-100MHz, so that should be fine. (For a little while I was confused by what seemed to be some heavy high-passing going on, but it turns out that the Fluke just can't push much low frequency FM; the manual says -3dB at 20Hz.)

Attachment 1: OLG_fastALS.pdf
OLG_fastALS.pdf
  14895   Wed Sep 18 12:40:09 2019 gautamUpdateCDSFast BIO Mapping at 1Y2

INCORRECT INFO IN THIS ELOG HAS BEEN REMOVED. SEE THIS ELOG FOR THE UPDATED INFO.

Summary:

With the help of a tester board, I verified the mapping between fast BIO DB37 pins, and pins on the IDC50 connectors that are to be broken out to the whitening boards. I will enlist Chub to implement this mapping in hardware later today.

Details:

  1. The LSC PD demodulated signals are optionally whitened before acquisition by our RTCDS ADCs.
  2. The switching of each channel's whitening (enable/disable) is done by a single bit from the fast (a.k.a. RTCDS) system's BIO cards.
  3. The whitening boards live inside Eurocrates.
  4. The aforementioned switching signal needs to be sent to the whitening boards via the backplane of the Eurocrate.
  5. This requires some cross-connect based cable splicing between the BIO card outputs and the P2 connectors of the whitening boards in the Eurocrates.
  6. This connection was accidentally destroyed during the war on cross-connects at 1Y2. I couldn't find a wiring diagram anywhere.
  7. Today, with the help of a tester board, I verified the mapping by toggling the appropriate channels on the MEDM screen, and verifying the correct LEDs on the tester board were toggled.
  8. Map will be posted here after the meeting... Also now on the wiki.

Update 2019 Sep 19 1730: The pin numbers of the IDC 50 connector are all off by 1. i.e. 3-->4 and so on. I will fix this shortly. The problem was because of me looking at the pinout for the wrong gender of IDC50 connectors.

  14901   Thu Sep 19 21:23:51 2019 gautamUpdateCDSFast BIO splicing re-implemented at 1Y2

[KA, GV]

Summary:

  1. New cross connect system for splicing the fast BIO signals for whitening switching to the P2 connectors was installed and tested at 1Y2.
  2. It passed a first round of tests. 😁 
  3. As of now, I believe all the necessary electrical connections have been made at 1Y2/1Y3, and we are ready for testing the c1iscaux system.

Details:

  1. We did some testing in the office area, and found several wiring mistakes. These were all rectified. Attachment #1 is an accurate reflection of the implemented wiring scheme (softcopy in the 40m google sheets area). Be aware that the IDC 50 pin connector pin-out is tricky, and you have to be aware of the difference between male/female connector when looking for this pin-out on the internet.
  2. In order to facilitate further testing, we re-routed the ADC0 SCSI cable that was unplugged on the overhead cable tray, and plugged it back into the c1lsc expansion chassis. This action necessitated a reboot of the vertex FEs, but everything came back alright.
  3. Did some general neatenign and strain relieving. Removed a few existing cross-connects to make space for our new terminal blocks.
  4. Attachment #2 shows the layout of the terminal blocks. Note the unusual (vertical) order of the orange terminal blocks.
  5. The final integrated CDS test done was the following:
    • Set whitening gain for channel under test to 45dB, so that the dark noise level is boosted to a measurable level such that a change can be seen with the whitening enabled/disabled.
    • Compare the ASD of the signal between 30-100 Hz with the whitening engaged/disengaged.
    • Example result shown in Attachment #3.I believe the whitening is 15:150 (z:p) 

Tomorrow:

  1. Recover POX/POY locking,.
  2. ...
Quote:

Update 2019 Sep 19 1730: The pin numbers of the IDC 50 connector are all off by 1. i.e. 3-->4 and so on. I will fix this shortly. The problem was because of me looking at the pinout for the wrong gender of IDC50 connectors.

Attachment 1: 1Y2_FAST_BIO_WIRING_MAP.pdf
1Y2_FAST_BIO_WIRING_MAP.pdf
Attachment 2: IMG_7949.JPG
IMG_7949.JPG
Attachment 3: REFL165.pdf
REFL165.pdf
  17018   Tue Jul 19 16:00:34 2022 yutaConfigurationBHDFast channels for BHD DCPDs now available in c1lsc but not in c1hpc

[Paco, Anchal-remote-support, Yuta]

We added fast channels to BHD DC PDs.
C1:LSC-DCPD_(A|B)_IN1 are now available, but C1:HPC-DCPD_(A|B)_IN1 still gives us zero.

c1hpc situation -> not good
 - We can see the slow signal at C1:X07-MADC1_EPICS_CH16 (DC PD A) and CH17 (DC PD B)
 - C1:HPC-DCPD_(A|B)_IN1 is there, but zero.
 - We have modified c1hpc model to add DCPD_(A|B) filters in front of the input matrix (see Attachment #1).
 - After modifying the model, we run
ssh c1sus2
rtcds make c1hpc
rtcds install c1hpc
ssh fb1
sudo systemctl restart daqd_*

 - After this, we got 0x2000 error. So, we ran the following. This removed 0x2000 error, but DCPD signals are still zero. They are also not available in C1HPC-MONITOR_ADC1.adl screen (see Attachment #3).
ssh c1sus2
rtcds restart c1hpc


c1lsc situation -> good
 - We could see the slow signal at C1:X04-MADC1_EPICS_CH4 (DC PD A) and CH5 (DC PD B), and also C1:LSC-DCPD_(A|B)_NORM after making C1:LSC-DCPD_(A|B)_POW_NORM=1. The ADC channel and DCPD channel are exactly the same.
 - After confirming the above, we modified the c1lsc model to add DCPD_(A|B) filters in front of the input matrix (see Attachment #2).
 - After modifying the model, we run
ssh c1lsc
rtcds make c1lsc
rtcds install c1lsc
ssh fb1
sudo systemctl restart daqd_*

 - After this, we also got 0x2000 error. We also noticed that, for example, C1:X04-MADC0_EPICS_CH31 and C1:LSC-ASDC_INMON are different, which used to be the same (ASDC_INMON was largely attenuated).
 - In the end, we run the following to remove 0x2000 error, but it crashed c1lsc, as well as c1sus, c1ioo.
ssh c1lsc
rtcds restart c1lsc

 - So, we did rebootC1LSC.sh. This made c1lsc, c1ioo and c1sus as green as before, except for RFM issue in TRX/TRY, like we saw in June. We followed the steps in 40m/16887 to hard reboot c1iscex/c1iscey and ran rebootC1LSC.sh again. This made C1CDS_FE_STATUS.adl screen as green as before (see Attachment #3).

 - Fast channels C1:LSC-DCPD_(A|B)_IN1 are now available. They are also available in C1LSC-MONITOR_ADC1.adl screen (see Attachment #3).

Attachment 1: Screenshot_2022-07-19_14-26-39_c1hpc.png
Screenshot_2022-07-19_14-26-39_c1hpc.png
Attachment 2: Screenshot_2022-07-19_14-24-49_c1lsc.png
Screenshot_2022-07-19_14-24-49_c1lsc.png
Attachment 3: Screenshot_2022-07-19_15-51-25_GreenGreen.png
Screenshot_2022-07-19_15-51-25_GreenGreen.png
  10016   Mon Jun 9 22:40:36 2014 JenneUpdateCDSFast front end computers up

Rana and I now seem to have the fast front end computers (c1lsc, c1sus, c1ioo, c1iscex and c1iscey) up and running!  Hooray!

It seemed that we needed to change the soft links back to hard links for rtcds and rtapps on the front end machines.  On c1ioo, we did:

cd /opt

sudo rm -rf rtcds

sudo rm -rf rtapps

sudo mkdir rtcds

sudo mkdir rtapps

sudo chown controls:1001 rtcds

sudo chown controls:1001 rtapps

mount /opt/rtcds

mount /opt/rtapps

At this time, the front end fstab had several other options in addition to "nolock" for both rtcds and rtapps.  They had rw,bg,user,nolock.  This state still had some permissions problems.  (Later, we have decided that perhaps our next step was unneccesary, since it still left us with (fewer) permissions problems. Taking out the rw,bg,user options from the front end fstab seems to have fixed all permissions issues, so maybe this next chmod step didn't need to be done.  But it was done, so I record it for completeness).

On chiara, we did:

cd /home/cds/rtcds

sudo chmod -R 777 *

Then on c1iscex, I didn't have to deal with the soft links, but I did need to mount the rtcds and rtapps directories so that I could see files in them.  I just did the last 2 operations from the c1ioo list above (mount /opt/rtcds and mount /opt/rtapps). 

Since we were still seeing some (fewer) permissions problems, we took out the extra options in the front ends' fstab that Rana had added.  Rebooting c1iscex after this, everything came back as expected.  Nice!

I think that, at this point, remotely rebooting (sudo shutdown -r now) the other front ends made everything come back nicely. Since we had gotten the fstab situation correct, we didn't have to by-hand mount any directories, and all of the models restarted on their own.  Finally!

 

 


For posterity, here are things that we'll want to remember:

Frame builder's fstab, in /etc/fstab (only the uncommented lines, since there are lots of comments):

/dev/sdb1               /               ext3            noatime         0 1
/swapfile               none            swap            sw              0 0
shm                     /dev/shm        tmpfs           nodev,nosuid,noexec     0 0
/dev/sda1               /frames         ext3    noatime         0 0
192.168.113.104:/home/cds/                      /cvs/cds        nfs     _netdev,auto,rw,bg,soft      0 0
192.168.113.104:/home/cds/rtcds                  /opt/rtcds     nfs     _netdev,auto,rw,bg,soft 0 0
192.168.113.104:/home/cds/rtapps                 /opt/rtapps    nfs     _netdev,auto,rw,bg,soft 0 0

Fast front end fstabs, which are on the framebuilder in /diskless/root/etc/fstab:

master:/diskless/root                   /               nfs     sync,hard,intr,rw,nolock,rsize=8192,wsize=8192    0 0
master:/usr                             /usr            nfs     sync,hard,intr,ro,nolock,rsize=8192,wsize=8192    0 0
master:/home                            /home           nfs     sync,hard,intr,rw,nolock,rsize=8192,wsize=8192    0 0
none                                    /proc           proc    defaults          0 0
none                                    /var/log        tmpfs   size=100m,rw    0 0
none                                    /var/lib/init.d tmpfs   size=100m,rw    0 0
none                                    /dev/pts        devpts  rw,nosuid,noexec,relatime,gid=5,mode=620        0 0
none                                    /sys            sysfs   defaults        0 0
master:/opt                             /opt            nfs     async,hard,intr,rw,nolock  0 0
192.168.113.104:/home/cds/rtcds         /opt/rtcds      nfs     nolock                     0 0
192.168.113.104:/home/cds/rtapps        /opt/rtapps     nfs     nolock                     0 0

  16009   Fri Apr 9 13:13:00 2021 Anchal, PacoUpdateSUSFaster coil balancing

We ran again this method but with the 'b' parameter as a matrix instead. This provides more gain on some off-diagonal terms than others. This gave us a better convergence with the code reaching to the tolerance level provided (0.01 distance of S matrix from identity) within 16 iterations (~17 mins).


Attachment 1 again shows how the off-diagonal terms go down and how the overall distance of sensing matrix from identity goes down. This is 'Cross coupling budget' of the coils as iterations move forward.


Jumping to near zero-crossing:

  • Rana mentioned a ezlockin code which first makes 5 step changes in output matrix without using feedback and calculates the changes required to reach zero-crossing in the behavior of the off-diagonal terms during these steps.
  • This is similar to what we did above by hand where we increased the value of b for slowly converging off-diagonal elements.
  • We plan to implement this 'jump' to near zero-crossing method next. Aim is to get a coil balancing code that does the job in ~5 min.
  • We have been throwing away imaginary part of sensing matrix so far. We wanted to get to some owrking solution before we try more complex stuff. We have to figure out global phases in each transfer function estimate to rotate the measured transfer function appropriately.
Attachment 1: SmatIterations.pdf
SmatIterations.pdf
Attachment 2: MC2AllOutmat.txt
1.027604652272846142e+00 1.193175249772460367e+00 1.091939557371080394e+00
1.010054273887021292e+00 1.156057452309880551e+00 -8.392112351146234772e-01
9.895057930131009316e-01 -7.685799469766890768e-01 6.200896409311776880e-01
9.719554146272761930e-01 -8.056977444392685594e-01 -1.311061151554526294e+00
  16010   Fri Apr 9 17:41:12 2021 ranaUpdateSUSFaster coil balancing

convergence is great.

Next we wanna get the F2A filters made since most of the IMC control happens at f < 3 Hz. Once you have the SUS state space model, you should be able to see how this can be done using only the free'swinging eigenfrequencies. Then you should get the closed loop model including the F2A filters and the damping filters to see what the closed loop behavior is like.

 

  16014   Sat Apr 10 10:07:47 2021 ranaUpdateSUSFaster coil balancing

I think I mis-spoke about the balancing channels before. The ~20 Hz balancing could go into either the COIL banks or the SUS output matrix.

I believe its more conceptually clean to do this as gains in the outputmatrix, and leave the coil gains as +/- 1. i.e. we would only use the coil gains to compensate for coil/magnet actuation strength.

Then the high frequency balance goes into the outputmatrix. The F2A and A2L decoupling filters would then be generated having a high frequency gain = 1.

  11521   Thu Aug 20 18:08:28 2015 IgnacioFrogs40m upgradingFatality. Something broke.

So I made coffee at 1547 and was astonished to find the above. Its a sad, very sad day.

At first I thought that something (a gravity wave?) or someone, accidentally hit the thing and it fell and broke. But Koji told me that the janitor was cleaning around the thing and it did indeed fell accidentally.

  3185   Fri Jul 9 11:09:14 2010 josephbUpdateComputersFb40m and a few other machines turned off briefly just before 11am

I turned off fb40m2 and fb40m temporarily while we added an extra power strip  to the (new) 1X6 rack at the bottom in the back.  This is to allow for the addition of the 4600 computer  given to us by Rolf (which needs a good name) into the rack above the fb machine.  The fb40m2 was unfortunately plugged into the main power connectors, so we unplugged two of its cables, and put them into the new strip. While trying to undo some of the rats nest of cables in the back I also powered down and unpluged briefly the c0dcu1, the pem crate, and the myrinet bypass box.

I am in the process of bringing those machines back up and restoring the network.

Also this morning, Megatron was moved from the end station into the (new) 1X3 rack, along with its router.  This is to allow for the installation of the new end computer and IO chassis.

 

  5218   Sat Aug 13 01:52:07 2011 YoichiUpdateLSCFeed forward delay
Yoichi, Koji

While I was testing the feed forward cancellation, I noticed that the
cancellation was not perfect.
The test I did was the following.
I injected the same signal to both DARM and MICH feedback filters.
This was done by injecting a signal into the excitation point of
the ASDC PD, then changing the input matrix elements so that the signal
goes to both DARM and MICH.
Then in the FFC, MICH signal was fed forward to DARM by the gain of -1.
Ideally, this should completely eliminate the DARM FB signal.
In reality, it did not.

The first PDF compares the spectrum of the injected noise (white noise,
red curve) with the spectrum of the signal after the FFC (blue curve).
At higher frequencies, the cancellation becomes poor.
It suggests that this is caused by some delay in the FFC.
I also took a transfer function from the injection point to the signal
after the FFC (second attachment).
I fitted the measured TF with a theoretical formula of
1-exp(-i*dt*f),
where dt is the time delay and f is the frequency.
The fitting is very good, and I got dt = 0.8msec ~ 13 samples for 16kHz.
13 samples is something very large.

The cause of the delay was suspected to be the shared memory communication
between different processes.
I moved all the FFC blocks to c1lsc.mdl.
Then the cancellation becomes perfect. The signal after the FFC is
completely zero, so I couldn't even make a TF measurement.

This results suggest that a large delay of 13 samples is induced
when you use shared memory to send signals round trip.
We should make simpler models, just passing signals back and forth
via shared memory, dolphin network or GE FANAC RFM to check the
delays more precisely.

For the moment, the FCC is included in the c1lsc model.
The MEDM screens were modified to account for this change.
c1ffc is stopped and removed from rtsystab.
Attachment 1: Spe1.pdf
Spe1.pdf
Attachment 2: TFFitting.png
TFFitting.png
  7424   Thu Sep 20 22:52:38 2012 DenUpdateMachineLearningFeedback controller

Quote:

I have uploaded to my directory a directory neural_plant. The most important file is reference_plant.c, which compiles with the command

 We would appreciate some plots. Learning curves of recurrent NN working as a plant are interesting. For harmonic oscillator your RNN should not contain any hidden layers - only 1 input and 1 output node and 2 delays at each of them. Activation function should be linear. If your code is correct, this configuration will match oscillator perfectly. The question is how much time does it take to adapt.

Does FANN support regularization? I think this will make your controller more stable. Try to use more advanced algorithms then gradient descent for adaptation. They will increase convergence speed. For example, look at fminunc function at Matlab.

  7661   Fri Nov 2 13:20:35 2012 MashaUpdateMachineLearningFeedback controller

Quote:

Quote:

I have uploaded to my directory a directory neural_plant. The most important file is reference_plant.c, which compiles with the command

 We would appreciate some plots. Learning curves of recurrent NN working as a plant are interesting. For harmonic oscillator your RNN should not contain any hidden layers - only 1 input and 1 output node and 2 delays at each of them. Activation function should be linear. If your code is correct, this configuration will match oscillator perfectly. The question is how much time does it take to adapt.

Does FANN support regularization? I think this will make your controller more stable. Try to use more advanced algorithms then gradient descent for adaptation. They will increase convergence speed. For example, look at fminunc function at Matlab.

Hi everyone,

I've been on break this week, so in addition to working at my lab here, I've done some NN stuff. In response to Den's response to my last post, I've included learning curve plotting capabilities, 

I've explored all of the currently documented capabilities of FANN (Fast Artificial Neural Network - it's a C library) (most likely, there are additions to the library floating around in open-source communities, but I have yet to look into those). There is extensive FANN documentation on the FANN website (http://leenissen.dk/fann/html/files/fann-h.html), but I'll cut it down to the basics here:

FANN Neural Network Architectures

standard: This creates a fully connected network, useful for small networks, as in the reference plant case 

sparse: This creates a sparsely connected network (not all of the connections between all neurons exist at all times), useful for large networks, but not useful in the reference plant case, since the number of neurons is relatively small

shortcut: This creates some connections in the network which skip over various hidden layers. Not useful in the harmonic oscillator case since there are no hidden layers. Probably won't be useful in a better-modeled referrence plant since this reduces the non-linear capabilities of the model.

FANN Training  

TRAIN_INCREMENTAL: updates the weights after every iteration, rather than after each epoch. This is faster than the other algorithms for the reference plant.

TRAIN_BATCH: updates the weights after training on the whole set. This should not be used on batches of data for the reference plant, seeing as the time history dependence of the plant is smaller than the size of the entire data set. 

TRAIN_RPROP: batch training algorithm which updates the learning parameter.

TRAIN_QUICKPROP: updates the learning parameter, and uses second derivative information, instead of just first derivative, for backpropagation. 

FANN Activation Functions

FANN offers a bunch of activation functions, including a function FANN_ELLIOT, which is essentially the "signmoid like" activation function Den and I used this summer, which runs in the order of multiplication and addition. The function parameters (steepness) can also be set.

FANN Parameters

As usual, the learning parameter can be set. While over the summer we worked with lower learning parameters, in the case of the harmonic oscillator reference plant, since the error is low after the first iteration, higher learning parameters (0.9, for example), work better. However, this is a very isolated case, and, in general, lower parameters, though convergence is slower, produce more optimal results. 

The learning momentum is another parameter that can be set - the momentum factor is a coefficient in the weight adjustment equation which allows for the difference in weights beyond the previous weight to be factored in. In the case of the reference plant, a higher learning momentum (0.9) is optimal, although in most cases, a lower learning momentum is optimal so that the learning curve doesn't oscillate terribly. 

 

FANN does not explicitly include regularization, but this can be implemented by checking the MSE  at each iteration against the MSE at the n previous iterations, where n is the regularization parameter, and stopping training if there is no significant decrease (also determined by a parameter). The error bound I specified during training was 0.0001

The best result for the reference plant was obtained using FANN_TRAIN_INCREMENTAL, a "standard" architecture, a learning rate of 0.9 (as explained above) and a learning momentum of 0.9 (these values should NOT be used for highly non-linear and more complicated systems). 

I have included plots of the learning curves - each title includes the architecture, the learning algorithm, the learning parameter, and the learning momentum if I modified it explicitly.

All of my code (and more plots!) can be found in /users/masha/neural_plant

On the whole, FANN has rather limited capabilities, especially in terms of learning algorithms, where it only has 4 (+ all of the changes one can make to parameters and rates). It is, however, much more intuitive to code with and faster han the Matlab NN library, although the later has more algorithms. I'll browse around for more open-source packages. 

Best,

Masha

standard_BATCH_0p35_ref_plant_lc.pngstandard_QUICKPROP_0p35_ref_plant_lc.pngstandard_RPROP_0p35_ref_plant_lc.pngstandard_INCREMENTAL_0p35_ref_plant_lc.png

standard_INCREMENTAL_0p9_0p9_ref_plant_lc.png

  5874   Fri Nov 11 13:35:19 2011 KatrinUpdateGreen LockingFeedback to ETMY

[Kiwamu, Katrin]

20111111_freq_supp.png

 

Red and blue curves: frequency fluctuation of the beat node between PSL and YARM laser.

Green and broen curves: Actuation on ETMY.  In ALS_CONTROL.adl  ETMY filter bank 4 and 5 were switched on. Gain was 0.3

 

Nice reduction of the frequency fluctuation.

 

Y axis is in volts^2 per counts. In order to go to MHz/sqrt(Hz) you have to take the square root and then times [20Volts/(2^16)counts]*[10Hz/0.04V].

 

Started to scan the cavity, but this didn't work. Green light all out of lock. IR beam was badly aligned to cavity. Now, my time is over and I have to leave you.

Thanks, for your help and the nice time.

  14327   Sun Dec 2 16:08:44 2018 JonOmnistructureUpgradeFeedthroughs for Vacuum Acromag Chassis

Below is an inventory of the signal feedthroughs that need to be installed on the vacuum Acromag crate this week.

Type Qty Connects to # Chs Signals
DB-37 female 1 Main AC relay box 18 Valve/roughing pump control
DB-9 female 5** Satellite AC relay boxes 3-4/box Valve control
DB-25 male 1 Turbo pump 1 controller 5 Pump status readbacks
DB-9 male 30 Valve position indicators 2/valve Valve position readbacks
DB-9 male 3 Roughing pump controllers 1/pump Pump status readbacks
DB-9 male 1 Cryo pump controller 2 Pump status readbacks

**The original documentation lists five satellite boxes (one for each test mass chamber and one for the beamsplitter chamber), but Chub reports not all of them are in use. We may remove the ones not used.

  16452   Fri Nov 5 20:35:10 2021 KojiUpdateBHDFeedthru / Optical Mounts

- New feedthrus [4xDB25 Qty 4 / 8xDB25 Qty 1] are placed on the wire shelf at the entrance -> Jordan, please clean them.

- There are plenty of 2" DLC mounts. There are also many 1.5" mounts but they are less useful.
  We need at least 3 1" moounts and 1 1" or 2" lens mount (and the lens). Let's purchase them on Thorlabs. I'll work on the order.

Attachment 1: P_20211105_200817.jpg
P_20211105_200817.jpg
  8319   Wed Mar 20 16:45:59 2013 ManasaBureaucracyAuxiliary lockingFetched NPRO from ATF

[Koji, Annalisa, Manasa]

NPRO with controller from ATF joins the 40m. We have put it on the POY table where we plan to use it for ABSL.

Attachment 1: P3203298.JPG
P3203298.JPG
Attachment 2: P3203299.JPG
P3203299.JPG
  15496   Mon Jul 20 19:21:16 2020 anchalSummaryALSFew proposals for Voyager ALS

I've added 4 proposed schemes for implementing ALS in voyager. Major thing to figure out is what AUX laser would be and how we would compare the different PSL and AUX lasers to create an error signal for ALS. Everywhere below, 2um would mean wavelengths near 2 um including the proposed 2128nm. Since it is not fixed, I'm using a categorical name. Same is the case for 1um which actually would mean half of whatever 2 um carries.


Higher Harmonic Generation:

  • We can follow the current system of ALS with using 1.5 times PSL frequency as AUX instead of second harmonic as 1 um is strongly absorbed in Si.
  • To generate 1.5 times PSL frequency, three stages would be required.
    • SHG: Second Harmonic Generation mode matched to convert 2um to 1um. If we are instead making 2 um from 1um to start with, this stage will not be required.
    • SFG: Sum Frequency Generation mode matched to sum 2um photon and 1um photon to give 0.65 um photon.
    • DPDC: Degenerate Parametric Down Conversion mode matched to convert 0.65 um to 1.3 um (which would be 1.5 times PSL frequency).
  • To compare, we can either convert pick-off from PSL to AUX frequency by doing the above 3 stages (Scheme II).
  • Or we can just do SHG and SFG at PSL pick-off and do another SHG at AUX end (Scheme I) to compare the AUX and PSL both converted to 0.65 um (which would be 2 times AUX and 3 times PSL frequency).
  • This method would have added noise from SHG, SFG and DPDC processes along with issues to be inefficiency of conversion.

Arbitrary AUX frequency:

  • We can get away with using some standard laser near 1.5 um region directly as AUX. Most probably this would be 1550 nm.
  • What's left is to devise a method of comparing 1.5 um and 2um frequencies. Following are two possible ways I could think of:

Using a frequency comb:

  • Good stable frequency combs covering the wavelength region from 1.5 um to 2 um are available of the shelf.
  • We would beat PSL and transmitted AUX separately with the frequency comb. The two beat note frequencies would be:
    \Delta_\text{PSL} = \nu_\text{PSL} - \nu_{CEO} - m_1 \nu_\text{Rep}
    \Delta_\text{AUX} = \nu_\text{AUX} - \nu_{CEO} - m_2 \nu_\text{Rep}
  • Here, m1 and m2 represent the nearest modes (comb teeth) of frequency comb to PSL and AUX respectively.
  • Carrier Envelope Offset frequency (\nu_{CEO}) can be easily generated by using an SHG crystal in front of the Frequency comb. This step is not really required since most of the modern frequency combs now comb with inbuilt zero \nu_{CEO} stabilization.
  • Mixing above beatnotes with \nu_{CEO} would remove \nu_{CEO} from them along with any noise associated with \nu_{CEO}.
  • Further, a Direct Digital Synthesis IC is required to multiply the AUX side RF signal by m1/m2. This finally makes the two RF signals to be:
    \nu_{A} = \nu_\text{PSL} - m_1 \nu_{Rep}
    \nu_{B} = \frac{m_1}{m_2}\nu_\text{AUX} - m_1 \nu_{Rep}
  • Which on mixing would give desired error signal for DFD as :
    \nu_\text{PSL} - \frac{m_1}{m_2}\nu_\text{AUX}
  • This method is described in Stenger et al. PRL. 88, 073601 and is useful in comparing two different optical frequencies with a frequency comb with effective cancellation of all noise due to the frequency comb itself. Only extra noise is from the DDS IC which is minimal.
  • This method, however, might be an overkill and expensive. But in case (for whatever reason) we want to send in another AUX at another frequency down the 40m cavity, this method allows the same setup to be used for multiple AUX frequencies at once.

Using a Transfer Cavity:

  • We can make another more easily controlled and higher finesse cavity with a PZT actuator on one of the mirrors.
  • In the schematic, I have imagined it has a triangular cavity with a back end mirror driven by PZT.
  • Shining PSL from one side of the transfer cavity and employing the usual PDH, we can lock the cavity to PSL.
  • This lock would require to be strong and wide bandwidth. If PZT can't provide enough bandwidth, we can also put an EOM inside the cavity! (See this poster from Simon group at UChicago)
  • Another laser at AUX frequency, called AUX2 would be sent from the other side of the cavity and usual PDH is employed to lock AUX2 to the transfer cavity.
  • So clearly, this cavity also requires coatings and coarse length such that it is resonant with both PSL and AUX frequencies simultaneously.
  • And, the FSS for AUX2 needs to be good and high bandwidth as well.
  • The transmitted AUX2 from the transfer cavity now would carry stability of PSL at the frequency of AUX and can be directly beaten with transmitted AUX from the 40m cavity to generate an error signal for DFD.
  • I believe this is a more doable and cheaper option. Even if we want to do a frequency comb scheme, this could be a precursor to it.

_________________________

EditTue Jul 21 17:24:09 2020: (Jamie's suggestion)

Using Mode Cleaner cavity as Transfer Cavity:

  • If we coat the mode cleaner cavity mirrors appropriately, we can use it to lock AUX2 laser (mentioned above).
  • This will get rid of all extra optics. The only requirement is for FSS to be good on AUX2 to transfer PSL (MC) stability to AUX frequency.
  • I've added suggested schematic for this scheme at the bottom.

 

Attachment 1: VoyagerALSSchemes.pdf
VoyagerALSSchemes.pdf VoyagerALSSchemes.pdf VoyagerALSSchemes.pdf VoyagerALSSchemes.pdf VoyagerALSSchemes.pdf
  13640   Fri Feb 16 22:19:07 2018 gautamUpdateGeneralFibel ALS input polarization tuning

After discussing with Koji, I decided to try and align the input beam polarization at the PSL fiber coupler to one of the special axes of the PM fiber. The motivation is to try and narrow down the source of the large RF beatnote amplitude drift I noticed and reported last night.

The setup for doing so is shown in Attachment #1 - essentially, I setup one of the newly purchased couplers in a mount, set up a PBS, and placed two photodiodes at the S and P ports of the PBS. The idea is to rotate the input coupler in its mount, thereby maximizing the PER (monitored on two Thorlabs PDA520s - I didn't check the gain balance of them). 

I spent ~30mins doing some preliminary trials just now, and, I was able to achieve a PER of ~1/20. But I think much better numbers were reported in this SURF project (although I'm not entirely sure I understand that measurement). I will spend a little more time tweaking the alignment. The procedure is tricky as at some point, simply rotating the mount reduces the mode-matching efficiency into the fiber so much that it is not possible to get a meaningful PER measurement from the photodiodes. I'm adjouring for now, more to follow...

Attachment 1: PER_setup.JPG
PER_setup.JPG
  13641   Mon Feb 19 14:27:25 2018 gautamUpdateGeneralFibel ALS input polarization tuning

Summary:

Current configuration of PSL free-space to fiber coupling is:

  • 3.25 mW / 4.55mW (~71%) coupling efficiency, both numbers measured with Ophir power meter, Filter OFF
  • \mathrm{PER} \doteq \frac{\mathrm{P_{fast}}}{\mathrm{P_{slow}}} (I choose to define it in this way as opposed to the reciprocal) of 75 (~19dB). The uncertainty in this number is large (see discussion), but I am confident that we have >10dB, which while isn't as good as can be, is sufficient for the main motivation behind this work.

Motivation:

I had noticed that the RF beat amplitude was fluctuating by up to 20dBm as viewed on the control room analyzer. As detailed in my earlier elog, I suspected this to be because of random polarization drift between the PSL and EX fields incident on the Fiber coupled PDs. Since I am confident the problem is optical (as opposed to something funny in the electronics), we'd like to be able to isolate which of the many fiber segments is dominating the contribution to this random polarization drift.

Some useful references:

  1. General writeup about how PM fibers work and PER. Gives maximum achievable PERs for a given misalignment of incident beam relative to one of the two birefringent axes.
  2. Another similar writeup. This one put me onto the usefulness of the alignment keys on the fibers.
  3. Thorlabs PM980 specs - this tells us about the orientation of the two axes for the kind of fibers we use.

Procedure and details:

  • The principle of operation behind polarization maintaining (PM) fibers is that intentional birefringence is introduced along two perpendicular axes in the fiber.
  • As a result of which light propagates with different phase velocity along these axes.
  • For an arbitrary incident field with E-field components along both axes, it is almost impossible to predict the output polarization as we do not know the length of propagation along each axis to sufficient precision (it is also uncontrolled w.r.t. environmental fluctuations). So even if you launch linear polarization into the fiber, it is most likely that the output polarization state will be elliptical.
  • But if we align the incident, linear polarization along one of the two axes, then we can accurately predict the polarizaiton at the output, to the extent that the fiber doesn't couple power in the two axes during propagation. I cant find a spec for the isolation between axes for the fiber we use, but the specs I could find for other fiber manufacturers suggest that this number is >30dB, so I think the assumption is a fair one.
  • A useful piece of information is that the alignment key on the fibers gives us information about the orientation of the birefringent axes inside the fiber. For the Thorlabs fibers, it seems that the alignment key lines up with the stress-inducing rods inside the fiber (i.e. the slow axis). I confirmed this by looking at the fiber with the fiber scope.
  • The PSL pickoff beam I am using for this setup is from the transmission of the PBS after the Faraday. So this field should have relatively pure P-polarization.
  • The way I have set up the fiber on the PSL table, the fast axis of the fiber corresponds to P-polarization (i.e. E field oscillates parallel to the plane of the optical table). Actually, it was this alignment that I tweaked in this work.
  • Using the information about the alignment key defining polarization axes on the fiber, I also set up the output fiber coupler such that the fast axis lined up as near parallel to the plane of the optical table as possible. In this way, the beam incident on the PBS at the output of my setup should be pure P-polarizaiton if I setup my input alignment into the fiber well.
  • I tweaked the rotation of the Fiber mount at the input coupler to maximize the ratio of P_p / P_s, as measured by the pair of PDs at the output. 
  • As #1 of my listed references details, you need to align the incident linear polarization to one of the two birefringent axes to closer than 6 degrees to achieve a PER of >20dB. While this sounds like a pretty relaxed requirement, in practise, it is about as good as we can hope to achieve with the mounts we have, as there is no feature that allows us to lock the rotational degree of freedom once we have optimized the alignment. Any kind of makeshift arrangement like taping the rotating part to the mount is also flaky, as during the taping, we may ruin the alignment.
  • Attachment #1 shows the result of my alignment optimization - the ratio P_p / P_s is about 75.
  • The uncertainty on the above number is large. Possible sources of error:
    • Output coupler is not really aligned such that fast axis corresponds to P-polarizaiton for the output PBS.
    • The two photodiodes' gain balance was not checked.
    • The polarization content of the input beam was not checked.
    • The PBS at the output could be slightly misaligned relative to the S/P polarization directions defined by the tabletop.
    • The PBS extinction ratio was not checked.
  • But anyways, this is a definite improvement on the situation before. And despite the large uncertainty, I am confident that P_p / P_s is better than 10dB.
  • Moreover, Steve and I installed protective tubing on the lengths of fiber that were unprotected on the PSL table, this should help in reducing stress induced polarization drifts in the fiber, at least in these sections of fiber.
  • So I think the next step is to monitor the stability of the RF beatnote amplitude after these improvements. At some point, we need to repeat this procedure for the EX and EY fibers as well.
  • If the large drifts are still seen, the only thing we can exclude as a result of this work is the section of fiber from the PSL light coupler to the beat mouth.
Attachment 1: IMG_6900.JPG
IMG_6900.JPG
  13177   Wed Aug 9 12:35:47 2017 gautamUpdateALSFiber ALS

Last week, we were talking about reviving the Fiber ALS box. Right now, it's not in great shape. Some changes to be made:

  1. Supply power to the PDs (Menlo FPD310) via a power regulator board. The datasheet says the current consumption per PD is 250 mA. So we need 500mA. We have the D1000217 power regulator board available in the lab. It uses the LM2941 and LM2991 power regulator ICs, both of which are rated for 1A output current, so this seems suitable for our purposes. Thoughts?
  2. Install power decoupling capacitors on the PDs.
  3. Clean up the fiber arrangement inside the box.
  4. Install better switches, plus LED indicators.
  5. Cover the box.
  6. Install it in a better way on the PSL table. Thoughts? e.g. can we mount the unit in some electronics rack and route the fibers to the rack? Perhaps the PSL IR and one of the arm fibers are long enough, but the other arm might be tricky.

Previous elog thread about work done on this box: elog11650

Attachment 1: IMG_3942.JPG
IMG_3942.JPG
  13204   Mon Aug 14 16:24:09 2017 gautamUpdateALSFiber ALS

Today, I borrowed the fiber microscope from Johannes and took a look at the fibers coupled to the PDs. The PD labelled "BEAT PD AUX Y" has an end that seems scratched (Attachments #1 and #2). The scratch seems to be on (or at least very close to) the core. The other PD (Attachments #3 and #4) doesn't look very clean either, but at least the area near the core seems undamaged. The two attachments for each PD corresponds to the two available lighting settings on the fiber microscope.

I have not attempted to clean them yet, though I have also borrowed the cleaning supplies to facilitate this from Johannes. I also plan to inspect the ends of all other fiber connections before re-installing them.

Quote:

Last week, we were talking about reviving the Fiber ALS box. Right now, it's not in great shape. Some changes to be made:

  1. Supply power to the PDs (Menlo FPD310) via a power regulator board. The datasheet says the current consumption per PD is 250 mA. So we need 500mA. We have the D1000217 power regulator board available in the lab. It uses the LM2941 and LM2991 power regulator ICs, both of which are rated for 1A output current, so this seems suitable for our purposes. Thoughts?
  2. Install power decoupling capacitors on the PDs.
  3. Clean up the fiber arrangement inside the box.
  4. Install better switches, plus LED indicators.
  5. Cover the box.
  6. Install it in a better way on the PSL table. Thoughts? e.g. can we mount the unit in some electronics rack and route the fibers to the rack? Perhaps the PSL IR and one of the arm fibers are long enough, but the other arm might be tricky.

Previous elog thread about work done on this box: elog11650

 

Attachment 1: IMG_7471.JPG
IMG_7471.JPG
Attachment 2: IMG_7472.JPG
IMG_7472.JPG
Attachment 3: IMG_7473.JPG
IMG_7473.JPG
Attachment 4: IMG_7474.JPG
IMG_7474.JPG
  13222   Wed Aug 16 20:24:23 2017 gautamUpdateALSFiber ALS

Today, with Johannes' help, I cleaned the fiber tips of the photodiodes. The effect of the cleaning was dramatic - see Attachments #1-4, which are X Beat PD, axial illumination, X Beat PD, oblique illumination, Y beat PD, axial illumination, Y beat PD, oblique illumination. They look much cleaner now, and the feature that looked like a scratch has vanished.

The cleaning procedure followed was:

  • Blow clean air over the fiber tip
  • First, we tried cleaning with the Q-tip like tool, but the results weren't great. The way to use it is to dip the tip in the cleaning solvent for a few seconds, hold the tip to the fiber taking into account the angled cut, and apply 10 gentle quarter turns.
  • Next, we tried cleaning with the wipes. We peeled out an approximately 5" section of the wipe, and laid it out on the table. We then applied cleaning solvent liberally on the central area where we were sure we hadn't touched the wipe. Then you just drag the fiber tip along the soaked part of the wipe. If you get the angle exactly right, the fiber glides smoothly along the surface, but if you are a little misaligned, you get a scratchy sensation. 
  • Blow dry and inspect.

I will repeat this procedure for all fiber connections once I start putting the box back together - I'm almost done with the new box, just waiting on some hardware to arrive.

 

Quote:

Today, I borrowed the fiber microscope from Johannes and took a look at the fibers coupled to the PDs. The PD labelled "BEAT PD AUX Y" has an end that seems scratched (Attachments #1 and #2). The scratch seems to be on (or at least very close to) the core. The other PD (Attachments #3 and #4) doesn't look very clean either, but at least the area near the core seems undamaged. The two attachments for each PD corresponds to the two available lighting settings on the fiber microscope.

I have not attempted to clean them yet, though I have also borrowed the cleaning supplies to facilitate this from Johannes. I also plan to inspect the ends of all other fiber connections before re-installing them.

 

Attachment 1: IMG_7476.JPG
IMG_7476.JPG
Attachment 2: IMG_7477.JPG
IMG_7477.JPG
Attachment 3: IMG_7478.JPG
IMG_7478.JPG
Attachment 4: IMG_7479.JPG
IMG_7479.JPG
  13246   Wed Aug 23 17:22:36 2017 gautamUpdateALSFiber ALS - reinstalled

I completed the revamp of the box, and re-installed the box on the PSL table today. I think it would be ideal to install this on one of the electronic racks, perhaps 1X2 would be best. We would have to re-route the fibers from the PSL table to 1X2, but I think they have sufficient length, and this way, the whole arrangement is much cleaner.

Did a quick check to make sure I could see beat notes for both arms. I will now attempt to measure the ALS noise with this revamped box, to see if the improved power supply and grounding arrangement, as well as fiber cleaning, has had any effect.

Photos + power budget + plan of action for using this box to characterize the green PDH locking to follow. 

For quick reference: here is the AM/PM measurement done when we re-installed the repaired Innolight NPRO on the new X endtable.

  13502   Thu Jan 4 12:46:27 2018 gautamUpdateALSFiber ALS assay

Attachment #1 is the updated diagram of the Fiber ALS setup. I've indicated part numbers, power levels (optical and electrical). For the light power levels, numbers in green are for the AUX lasers, numbers in red are for the PSL.

I confirmed that the output of the power splitter is going to the "RF input" and the output of the delay line is going to the "LO input" of the demodulator box. Shouldn't this be the other way around? Unless the labels are misleading and the actual signal routing inside the 1U chassis is correctly done :/

  • Mode-matching into the fibers is rather abysmal everywhere.
  • In this diagram, only the power levels measured at the lasers and inputs of the fiber couplers are from today's measurements. I just reproduced numbers for inside the beat mouth from elog13254.
  • Inside the beat mouth, the PD output actually goes through a 20dB coupler which is included in this diagram for brevity. Both the direct and coupled outputs are available at the front panel of the beat mouth. The latter is meant for diagnostic purposes. The number of -8dBm of beat @30MHz is quoted using the direct output, and not the coupled output.

Still facing some CDS troubles, will start ALS recovery once I address them.

Attachment #2 is the svg file of Attachment #1, which we can update as we improve things. I'll put it on the DCC 40m tree eventually.

Attachment 1: FiberALS.pdf
FiberALS.pdf
Attachment 2: FiberALS.svg.zip
FiberALS.svg.zip
ELOG V3.1.3-