Goal:

 To interface the Mini Circuits RF Frequency Counter(FC) Model UFC-6000 with Raspberry Pi on Linux platform. Also to create a User friendly interface, to control the FC with command lines.

Highlights of the Code(script attached):

The  code enables the user to communicate and control different parameters of the UFC like:

1)Frequency Range Selection( for the device to read different frequencies, AutoRange is set by default).

2)Sampling Time (The time intervals for which the data will be retrieved)

3)Read Device Status(Whether the device is reading data or not).

Description of the Code:

HID USB Interfacing by sending byte Values.

 1)Read The Freq or Range 

Reading the Freq is done by reading the 1st and 2nd LCD of the Frequency counter.

1st line containing Range information, 2nd line is the Frequency result

the code should be send is 2

1st byte: 2

The returned 64 byte array is as follows:

1st byte: 2

2nd byte to Byte17 the ascii value of 16 characters of the 1st LCD line

Byte18 to Byte33  the ascii value of 16 characters of the 2nd LCD line

2) Set the Range  

By default Freq Counter is in "AutoRange" mode.

To set the range manually send the code 4

1st byte: 4

2nd byte: the range value. can be any legal range value. for auto range  need to be 255.

the 64 byte array is:

1st byte: 4

3)Set the Sample Time   

By default Freq Counter Sample Time is 1 sec.

you can set the sample time from 0.1 sec and up in step of 0.1 sec.To set the Sample Time send the code 3

1st byte: 3

2nd byte: the sample value in sec double 10.

for example: to set the sample time  to 0.4 sec 2nd byte need to be: 4

the 64 byte array is:

1st byte: 3

These bytes can be changed by changing the values of buffer[0] and buffer[1]  in function /*Send Report to the device*/ in the main program.

The data is written into a .txt file(example attached) and the user can  control the recording of data. The frequency data can now be made to talk to EPICS through slow channels.

The data from the .txt file can be used for error analysis at different sampling periods.

Results:

The interface of the FC with the Pi is now complete.

Plan:

 Make this FC talk to EPICS through slow channels.

Not sure if someone is already on this, but the nodus DokuWikis are still down (AIC, ATF, Cryo, etc.)

I get:

DokuWiki Setup Error

The datadir ('pages') does not exist, isn't accessible or writable. You should check your config and permission settings. Or maybe you want to run the installer

I really think it's a bad idea to be making all these names changes.  You're making things much much harder for yourselves.

Instead of repointing everything to a new host, you should have just changed the DNS to point the name "linux1" to the IP address of the new server.  That way you wouldn't need to reconfigure all of the clients.  That's the whole point of  name service: use a name so that you don't need to point to a number.

Also, pointing to an IP address for this stuff is not a good idea.  If the IP address of the server changes, everything will break again.

Just point everything to linux1, and make the DNS entries for linux1 point to the IP address of chiara.  You're doing all this work for nothing!

RXA: Of course, I understand what DNS means. I wanted to make the changes to the startup to remove any misconfigurations or spaghetti mount situations (of which we found many). The way the VME162 are designed, changing the name doesn't make the fix - it uses the number instead. And, of course, the main issue was not the DNS, but just that we had to setup RSH on the new machine. This is all detailed in the ELOG entries we've made, but it might be difficult to understand remotely if you are not familiar with the 40m CDS system.

Rana mentioned this in his elog entry re: SLOW computer recovery, but I want to highlight it:

We cannot yet lock the mode cleaner.

It seems that we need to be aware of the sticky slider issue that we have seen for years (although don't deal with too often) that a burt restore will make it seem like an EPICS channel is at some value, but in fact it is at some other value.  For any sliders or buttons in question, change the value by some amount, and then change it back.  This forces things to refresh, and it'll then be at the value that is reported.

However, for the MC board, this seems to not be enough.  Changing the offset slider doesn't seem to actually change the offset value.  The fast output of the MC board is railed at 9.996 V.  So.  We need to check out the MC servo board and ensure that we are actually connected and talking to it through the c1iool0 (C1i-oh-oh-L-zero, to make the characters more clear) slow machine.

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

 All of the SLOW computers were in limbo since the fileserver/nameserver change, but me and Zach brought them back.

One of the troubles, was that we were unable to telnet into these computers once they failed to boot (due to not having a connection to their bootserver).

1. Needed special DB9-RJ45 cable to connect from (old) laptop serial ports to the Motorola VME162 machines (e.g. c1psl, c1iool0, c1aux, etc.); thanks to Dave Barker for sending me the details on how to make these. Tara found 2 of these that Frank or PeterK had left there and saved us a huge hassle. Most new laptops don't have a serial port, but in principle there's a way to do this by using one of our USB-Serial adapters. We didn't try this, but just used an old laptop. The RJ45 connector must go into the top connector of the bottom 4; its labeled as 'console' on some of the VME computers. Thanks to K. Thorne for this very helpful hint and to Rolf for pointing me to KT.
2. Installed 'minicom' on these machnes to allow communication via the serial port.
3. Had to install RSH on chiara to allow the VME computers to connect to it. Also added the names of all the slow machines in /etc/hosts.equiv to allow for password-less login. Without this they were not able to load the vxWorks binary. It was tricky to get RSH to work, since its an insecure and deprecated service. 'rsh-server' doesn't work, but installing 'rsh-redone-server' did finally work for passwordless access. Must be that linux1 has RSH enabled, but of course, this was undocumented.
4. Some of the SLOW machines didn't have their own target names or startup.cmd in their startup boot parameters (???). I fixed these.
5. For C1VAC1, I have updated the boot parameters via bootChange, but I have not rebooted it. Waiting to do so when Koji and Steve are both around. We should make sure to not forget doing this on C1VAC2. Steve always tells us that it never works, but actually it does. It just crashes every so often.
6. Leaving C1AUXEX and C1AUXEY for Q and Jacy to do, to see if this ELOG is good enough.
7. The PSL crate still starts up with a SysFail light turned on red, but that doesn't seem to bother the c1psl operation. We (Steve) should go around and put a label on all the crates where SysFail is lit during 'normal' operation. Misleading warning lights are a bad thing.

We still don't have control completely of the MC Servo board, so we need the morning crew to start checking that out

An example session (using telnet, not the laptop/serial way) where we use bootChange to examine the correct c1aux config:

controls@pianosa|target> telnet c1aux
Trying 192.168.113.61...
Connected to c1aux.martian.
Escape character is '^]'.

c1aux > bootChange

'.' = clear field;  '-' = go to previous field;  ^D = quit

boot device          : ei
processor number     : 0
host name            : chiara
file name            : /cvs/cds/vw/mv162-262-16M/vxWorks
inet on ethernet (e) : 192.168.113.61:ffffff00
inet on backplane (b):
host inet (h)        : 192.168.113.104
gateway inet (g)     :
user (u)             : controls
ftp password (pw) (blank = use rsh):
flags (f)            : 0x0
target name (tn)     : c1aux
startup script (s)   : /cvs/cds/caltech/target/c1aux/startup.cmd
other (o)            :

value = 0 = 0x0
c1aux >

#!/bin/bash   ### this is a comment  PATH=$PATH:/home/user/path    echo "How cool is this?" 

EDIT: it looks like the code highlighting is sort of broken :-(.

The SVN Apache server was not happy trying to read from /cvs/cds/caltech/svn/; it complains "Value too large for defined data type" when trying to modify certain files.

To remedy this, Eric ran an rsync job to copy over the svn directory to /export/home/svn/, which is directly on nodus rather than on the NFS mount.

Accordingly, I edited the httpd-ssl.conf file in /cvs/cds/caltech/apache/etc/ so that SVNPath points to /export/home/svn. The original config file is preserved as httpd-ssl.conf.old_20140609.

Then I started the Apache server using the instructions on the 40 m wiki (search "Apache"). The SVN now appears to be working fine; you can svn up and svn ci as necessary.

However, this means that we now need to start backing up /export/home/svn/, rather than the NFS-mounted directory.

How is the modulation depth assumed in the calculation?

If you don't know the modulation depth, you can't calibrate the transimpedance of each PD individually.

In all of the fstabs, we're using chiara's IP instead of name, so that if the nameserver part isn't working, we can still get the NFS mounts.

On control room computers, we mount the NFS through /etc/fstab having lines like:

192.168.113.104:/home/cds /cvs/cds nfs rw,bg 0 0
fb:/frames /frames nfs ro,bg 0 0

Then, things like /cvs/cds/foo are locally symlinked to /opt/foo

For the diskless machines, we edited the files in /diskless/root. On FB, /diskless/root/etc/fstab becomes

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

("master" is defined in /diskless/root/etc/hosts to be 192.168.113.202, which is fb's IP)

and /diskless/root/etc/resolv.conf becomes:

search martian

nameserver 192.168.113.104 #Chiara

Current computer status:

All fast machines except c1iscey are up and running. I can't ssh to c1iscey, so I'll need to go down to the end station and have a look-see. On the c1lsc machine, neither the c1oaf nor the c1cal models are running (but for the oaf model, we know that this is because we need to revert the blrms block changes to some earlier version, see Jamie's elog 9911).

Daqd process is running on framebuilder.  However, when I try to open dataviewer, I get the popup error saying "Can't connect to rb", as well as an error in the terminal window that said something like "Error getting chan info".

Slow machines c1psl, c1auxex and c1auxey are not running (can't telnet to them, and white boxes on related medm screens for slow channels).  All other slow machines seem to be running, however nothing has been done to them to point them at the new location of the shared hard drive, so their status isn't ready to green-light yet.

Things that we did on Friday for the fast machines:

The shared hard drive is "physically" on Chiara, at /home/cds/.  Links are in place so that it looks like it's at the same place that it used to be:  /opt/rtcds/...... 

The first nameserver on all of the workstation machines inside of the file /etc/resolv.conf has been changed to be 192.168.113.104, which is Chiara's IP address (it used to be 192.168.113.20, which was linux1).  This change has also been made on the framebuilder, and in the framebuilder's /diskless/root/etc/resolv.conf file, which is what all of the fast front ends look to. 

On the framebuilder, and in the /diskless place for the fast front ends, presumably we must have changed something to point at the new location for the shared drive, but I don't remember how we did that [ERIC, what did we do???]

The slow front ends that we have tried changing have not worked out. 

First, we tried plugging a keyboard and monitor into c1auxey.  When we key the crate to reboot the machine, we get some error message about a "disk A drive error", but then it goes on to prompt pushing F1 for something, and F2 for entering setup.  No matter what we press, nothing happens.  c1auxey is still not running.

We were able to telnet into c1auxex, c1psl, and c1iool0.  On each of those machines, at the prompt, we used the command "bootChange".  This initially gives us a series of:

$ telnet c1susaux
Trying 192.168.113.55...
Connected to c1susaux.
Escape character is '^]'.

c1susaux > bootChange

'.' = clear field;  '-' = go to previous field;  ^D = quit

boot device          : ei
processor number     : 0
host name            : linux1
file name            : /cvs/cds/vw/mv162-262-16M/vxWorks
inet on ethernet (e) : 192.168.113.55:ffffff00
inet on backplane (b):
host inet (h)        : 192.168.113.20
gateway inet (g)     :
user (u)             : controls
ftp password (pw) (blank = use rsh):
flags (f)            : 0x0
target name (tn)     : c1susaux
startup script (s)   : /cvs/cds/caltech/target/c1susaux/startup.cmd
other (o)            :

value = 0 = 0x0
c1susaux >

If we go through that again (it comes up line-by-line, and you must press Enter to go to the next line) and put a period a the end of the Host Name line, and the Host Inet (h) line, they will come up blank the next time around.  So, the next time you run bootChange, you can type "chiara" for the host name, and "192.168.113.104" for the "host inet (h)".  If you run bootChange one more time, you'll see that the new things are in there, so that's good.

However, when we then try to reboot the computer, I think the machines weren't coming back after this point.  (Unfortunately, this is one of those things that I should have elogged back on Friday, since I don't remember precisely).  Certainly whatever the effect was, it wasn't what I wanted, and I left with the machines that I had tried rebooting, not running.

My SURF week-1 work...

Motivation:

To measure the transimpedence of  the Broadband photodiode (D1002969-v8), using a New focus photodiode (1611) as reference. The amplitude modulated Jenne Laser (1.2mW) was used. 

The steps involved in getting the transimpedence are as follows:

Acquiring data

• Get 2 sets of data from Network Analyzer Agilent 4395: One set of data will be for the transfer function of Ref PD over RF out. The other set for Test PD over Ref PD.
• The following conditions were set:

1) Frequency sweep range: 1MHz to 200 MHz.

2) Number of Points sampled in  the range: 201

3) Type of sweep: Logarithmic

• Set the NA to give the corresponding transfer function values in dB and also Phase response in degrees.
• Save the data into floppy disk for processing on the computer (The wireless way of acquiring data was not working when the experiment was conducted )

Plotting

• The matlab code attached (TransimpedencePlot.m) will then give plots for the absolute values of transimpedence in V/A.
• Logic involved in the code:
  • Transimpedence = Voltage response / (Responsivity of the photodiode * Power incident) 
  • Responsivity for BBPD is taken as 0.1 A/W and for NF1611 as 0.68 A/W as given in their datasheets.
  • Voltage response of Test PD w.r.t RF output of NA (in dB) = Voltage response of Test PD w.r.t Ref PD (in dB) + Voltage response of Ref PD w.r.t RF output of NA (in dB) 

 Results

The Plots of transimpedence obtained are attached (results.pdf) . The results obtained for BBPD is consistent with the ones obtained before, but the same method and code gives a different transimpedence for 1611.

The transimpedence of NF 1611 was obtained to be around 4-5 V/A which is very much off-track compared to the one given in the datasheet (elog: 2906).

The transimpedence of  Broadband photodiode (D1002969-v8) was around 1200 - 1300 V/A for most of the range, but the value started falling as the frequency approached 100 MHz. This result is consistent with DCC document: T1100467-v2.

 Motivation: 

2014 surf students Nichin and Akhil received 40m specific basic safety training last week.

ELOG is back up and running after last Friday's disk-crash-a-thon. SVN is still a work in progress. Jenne and I are now restarting computers and such.

Sorry, the X arm is completely misaligned. This is the configuration I first tried in ELOG 9859, that is: a PRM->ITMY recycling cavity and ITMY->ETMY arm cavity. ITMX is completely misaligned, so the BS is dumping much of the recycling cavity light out, which is why I wrote "low finesse." This is the first time I've used REFL11 to control any of our cavities, though.

Wait. It is not so clear.

Do you mean that the IFO was locked with REFL11I for the first time?

Why is it still in the "low finesse" situation? Is it because of misalignment or the non-zero CARM offset?

Ant season has set in. I spotted and killed  a few ants around the optics and the enclosure of the PSL table yesterday. TIme for our pest control crew to get busy!

I'll put more detail in the morning, but I was able to get the PRM/ITMY/ETMY coupled cavities locked with 32kHz bandwidth using the AO path. (However, this is a pretty low-finesse situation, since the BS is dumping so much power out of the PRC. Full buildup is only 3 or 4 times the single arm power)

Since our ALS is better than it was a month ago when I last played with this, I was able to hop straight from ALS to REFL11 I on resonance, with the PRY locked on 3f.

Here are some quick OLTF plots I took along the way.

I'm using this configuration to validate my loop modelling for the full double arm case. Right off the bat, this tells me that the "minus" polarity on the CM servo is the correct one. I didn't use REFLDC at all tonight, but I figure I can check it out by doing the transition backwards, so to speak.

If the PD is the suspect, just pull it from the table and bring it to the PD testing setup.

The transimpedance of the PD should be ~2000 Ohm for both of the RF and DC outputs.

The test setup gives you the systematic opportunity for examination of the signal line.
Check the signal level with the active probe.

Once the broken component is found replace it. You are supposed to have the replacement
components on the blue tower.

I made my attempts trying to figure out what was wrong.

Checking if we are at the right X end laser temperature: 
I aligned the arms and found the Y beatnote.I blocked the light falling on the X beat PD so that the RF analyser was only looking at the output from the Y beat PD. AT the RF analyser, I found the strong Y-PSL beatnote, the X-Y beat note and a weak  X-PSL beatnote. This confirmed that we have the X end laser at the right temperature to be able to detect the beatnote. Unblocking the light on the X beat PD did not bring in any additional peaks. 

Checking the RF cabling from the X beat PD to the beat box:
I swapped the RF cables such that the signal from the Y beat PD output was going to the X input on the beatbox. I could still see the beatnote on the RF analyser. This confirmed that there aren't any broken RF cables along the X path.

Checking X green PSL alignment:
I replaced the X beat PD with the Y beat PD to check if the alignment of X&PSL green are alright. I could find the X beat note this way without any alignment tweaking.

I suspect we probably have some RF component burnt in the X beat PD. Do we have any spares lying around? There is a Koji's box with a PD having the same serial number.

IFO status report for anyone who is looking to do some locking tonight : 
The Y beat PD is back along the Y path and I have confirmed the presence of Y-PSL beat note after replacing the PD.
The X beat PD has been removed and now rests on the electronics bench for checking. 

While aligning the arms today, I noticed that enabling LSC would cause misalignment of the ETMY suspension. I haven't tried to find out what has been causing this. Could be something similar to what was noticed with the ETMX suspension a couple of weeks ago elog9969.  

I realigned the MC mirrors and brought down MC_REFL to 0.42 and MC_TRANS_SUM came up to ~ 17400 counts.

I measured the spot positions after alignment. MC1 and MC3 are slightly off in pitch :

spot positions in mm (MC1,2,3 pit MC1,2,3 yaw):
[2.0535418031770249, 0.84870716159663184, 1.9759940800847962, -1.6706240175650202, 0.089441353070240759, -1.0339963871771678]

I reset the WFS filterbank offsets and engaged the MCWFS servo. Atleast now the MC is not being thrown out of lock with WFS enabled. I have NOT touched the alignment to the WFS PDs.

 The bearing is chirping in the back of the 2W Innolight laser controller. It is loud enough to hear it. I placed 4 soft  rubber feet under the controller to avoid shaking other things on self.

The HEPA filter bearing becomes noisy at 50V

 Keep it at 20V for low noise

Also, while I was working on the PSL table, I heard noise that sounded like a bearing rolling around.  I suspected the HEPAs, since the one on the north east corner of the table has a problem when it's turned up high (we've known about this for a long time), however turning off the HEPAs didn't affect the noise.  The noise is strongest near the back of the PSL controller on the shelf above the table, and the PSL controller box is vibrating.  So, I suspect that the fan on the PSL controller box is about to give out.

EDIT:  To clarify, I mean the Innolight's controller.

Grr.  I am very frustrated.  After lunch I redid alignment for both X and Y green systems (Yarm both at the end and on the PSL table, Xarm just on the PSL table).  After that realignment work, I cannot find a beatnote for the Xarm!!! 

The Ybeat, after aligment, was up to -5.5 dBm when the beat was at 11 MHz. Last week it was something like -20 dBm, so alignment makes a big difference.  After doing IR alignment I had noticed that the green transmitted through the Yarm didn't look very bright on the camera, and the power was around 0.2, so I went to the Yend and gently touched the green input steering mirrors, and got the Ygreen trans PD back to more than 0.9 with the PSL green shutter closed.  Awesome.  Then I touched up the Ygreen PSL alignment, and then saw that the beatnote was nice and large.  Hooray.  I measured the out of loop noise, and it was even better than the best we saw last week:  (greenish was best last week for Yarm, teal blue is new Ygreen):

At this point, I still hadn't touched anything on the X path (except the PZT input steering mirrors, remotely from the control room).  The beatnote was about the same size as it was on Friday, around -27dBm.  I went onto the PSL table and did the same alignment procedure that I had just done for the Yarm:  Remove the green trans PD and the accompanying lens so that I get far-field spots on the wall, and then steer the PSL green and the X green spots until they are nicely overlapped at both the camera (near-field) and on the wall.  I looked at the DC output of the beat PD, and centered the beam on the diode.  I put back the thorlabs DC transmission PD and the lens, and centered the beam on that.  However, after this work, I cannot find a beatnote for the X arm!  I still see the nice big Ygreen beatnote, and I have the PSL and Xend temperatures where they usually are (  abs(FSS Slow) < 0.1, and X end Slow around 10,090. )  I scanned -10,000 counts, and +5,000 counts from there, and still don't find a beatnote!

I went back inside, and I don't see an RF signal coming into the beatbox from the Xarm.  It's not the cable's fault though, since I then hooked the RF output of the beat PD to a 'scope, and still didn't see any beatnote.  The DC path of the PD is definitely seeing things, because when I switch the 'scope over to the DC output of the Xbeat PD, and I block/unblock the beam, I see the voltage step up and down as expected. 

I have not pulled out the Xgreen broadband PD, but unless someone else has a good idea of what to check, that might be one of the next things to do. 

Ideas of things I could try:

* Put the X broadband PD on the Y beatnote path to see if I see the same Y beatnote (use the port where the Y green trans PD is, since it has the coaligned beams, and a lens).

* Open the PD and see if anything on the RF path is fried.

* Move the Y PD over to the X path, to see if it sees the beatnote.

* ????

Sorry, I had been in a hurry when I worked on this last week, and again when I wrote the elog, but I wanted to at least put in a note for any weekend workers.

The ALS beatnote setups need alignment on the PSL table.  However, even at very low RF beat frequency, the X beatnote now at low frequencies matches our best measurement from last week.  The "HEPA off" (teal and purple) measurements are from last week, and the red and blue are from this week.  The X beatnote was 10MHz and the Y beatnote today was 31MHz.

 Rga scan at pump down 77, vacuum normal valve configuration, maglev rotation 560 Hz and day 111

I came in and PMC transmission was at 0.5V, and ETMX was swinging around a lot, (LSC mode was on). 

Turning off oplevs let ETMX calm down. I realigned the PMC to 0.82V. 

MC wouldn't relock, it looked misaligned in pitch and yaw on MC camera.

I've touched the alignment, and gotten the reflection below 0.5, but it unlocks periodically, spot positions aren't great, and turning on WFS throws it out of alignment. ughhhhh

And the out-of-loop level of the ALSX compared with the previous measurement is ...?

I just realized that I forgot to elog this, but yesterday afternoon I bypassed the amplifier in the BeatX path, and now the X beatnote is about -27dBm.  Arms lock nicely with ALS.

The Y arm green transmission had come down to 0.3 and the green steering mirrors on the Y end table required some minor alignment adjustments to bring back transmission to around 0.75 counts.

 I added two green glass absorbers. The oplev centering may need a touch up when it is well aligned.

Below are the transfer functions measured between the angular (pit, yaw) motion of X arm mirrors and the ALSX error signal. The measurements were again made for 1Hz-30Hz.

The transfer functions are mostly flat.

ITMX P - 200-300 Hz/urad (beat freq = 45 MHz)

ITMX Y - 700-800 Hz/urad (beat freq = 27MHz)

ETMX P - 500-600 Hz/urad (beat freq = 56 MHz)

ETMX Y - 1000-2000 Hz/urad (beat freq = 62.5MHz)

Data xml files can be found in /users/manasa/data/140521/

PMC has been unlocked for ~4hrs, not sure why. It's servo gain was down at -10dB...

Relocked with transmission of .76V, MC locks fine with WFS, transmission of 15.5k.

Tektronix RECALL on TDS3000 or TDS300B  oscilloscope BATTERIES TDS3BATB

This Lithium-Ion battery can be a fire hazard !  Remove battery pack and recycle it through Safety Office !

Attached is the measurement of the transfer function from ITMX oplev error in yaw to the ALSX error signal.

The arm was locked to the IR using POX and the green beat frequency (between X arm trans in green and PSL green) in this case was 27MHz.

The transfer function looks mostly flat between 1Hz - 30Hz at 700-800 Hz/urad. The DC shift that Jenne measured from the time series is ~500 Hz/urad.

So far I have not been able to measure the TF below 1Hz without the arm losing its lock. Updates will follow.

Data xml file can be found in /users/manasa/data/140521/

I fixed a bug in the SUS_SINGLE screen, where the total YAW output was incorrectly displayed (TO_COIL_3_1 instead of TO_COIL_1_3). I noticed this by seeing that the yaw bias slider had no effect on the number that claimed to be the yaw sum. The first time I did this, I accidently changed the screen size a bit which smushed things together, but that's fixed now.

I committed it to the svn, along with some uncommitted changed to the oplev servo screen.

I found MC unlocked this morning. I looked at the 2 day trend of the MC suspensions and found MC2 suspensions have been misaligned.

I used Rana's ezcaservo trick to recover MC lock. This brought the MC_REFL down to 0.7 counts. I did the rest of the alignment by moving the MC2 suspension sliders only. MC_REFL is down to 0.45-0.5 counts and TRANS_SUM is at ~16300.

Also, I found the WFS servo was left turned OFF. I re-enabled them as well.

 There are 9 razor beam dumps at ETMY-ISCT

[Rana, Jenne]

We spent some time tonight looking at locking the PRMI with REFL165 vs. REFL33, while reducing the CARM offset. 

We were not able to lock the PRMI on REFL165 I&Q at small CARM offsets.  When locking at larger CARM offsets (about 100 counts, which is about 100nm) and then re-adjusting the REFL165 demod phase as I reduced the CARM offset, I saw that I had to significantly rotate the phase.  For PRMI only (no arms), the REFL165 demod phase was -138.5 deg.  When the PRMI was locked with a -100 count CARM offset, the optimal demod phase was -123 deg.  Then at -90 counts the phase was -113 deg.  At -70 counts, the phase was -108 deg, at -50 counts it was -98 deg, and at -40 it was -93 deg.  We want to go back and look at these more carefully, and in a more continuous way, by watching the sensing matrix calibration lines.  It's unclear to me right now why we're seeing this, but it's possible that we're getting some kind of extra 55MHz resonances.

REFL DC looks like it should be good - same slope and gain as sqrtTR, extra 20 or 30 deg of phase margin, so we think that we should be able to transition over to it, and then try engaging the AO path.  Tonight we had Den's new 1kHz lowpass engaged, and with this, everything looks nice and stable.

Game plan:  Bring CARM in until transmissions are at about 10ish, then try keeping CARM on sqrtInvTrans for the DC part, and engage the AC AO part with REFL DC.  We probably just need to try this for a while more to find just the right way to turn it on.

Need to think about demod phase rotation vs CARM offset as well as extra resonances, but this may take a while, and if we can just get the AO path engaged, that would be good.

Since Q has found that REFL165 will be better for holding the PRMI while we reduce the CARM offset, I had a look at locking PRMI sideband locking with both 3f PDs.

I checked the REFL165 demod phase, and changed it from -142.5 deg to -138.5 deg. to minimize the Q signal while driving PRM length.

I found that keeping the MICH and PRCL loop gains the same, and using matrix elements +0.1 for both I and Q for REFL165, rather than +1 for both I and Q for REFL 33.

MICH gain is +0.8, PRCL gain is -0.02.  FMs 4,5 on for both, FM 2 triggered for MICH, FMs 2,3,6 triggered for PRCL.

I then locked the PRMI on sideband with REFL 33 and then REFL 165, and measured the other one as an out of loop sensor of the motion.  I find that REFL33 and 165 are both comparable, and so we shouldn't have any trouble using REFL165 for locking.

 Here's the angles of MICH and PRCL from the my earlier plot by themselves; this shows that the individual demod angles in REFL165 aren't changing much either. 

So, I really should have done this as soon as Manasa measured the arm lengths... I've updated my MIST model with the real arm lengths, but still am using assumed identical losses of 75ppm on each mirror. (I've tried measuring the arm losses for real, but got numbers in the hundreds of ppms, so I need to reexamine things...) 

Here's a simulation of the fields in a perfectly locked PRC when CARM is swept (Normalized to input power = 1). 

More importantly, here's the latest simulation of MICH vs. PRCL demodulation angle separation in the 3F signals. It seems that we may be getting burned by using REFL33 for the PRC lock. REFL165, on the other hand looks much more robust. We should try this out. 

(Some of my previous simulations incorrectly implemented MICH excitations; I only moved the ITMS, not the ETMS along with them, so some other stuff slipped in... )

 This QPD circuit (D980325-C1 ) uses the nice OP497 Quad FET opamp as the transimpedance amplifier. It has a low enough current noise, such that we can increase the resistors (R1-4) up to 100k and still be Johnson noise limited. We should also make sure that the compensation caps (C3-6) are ~2.2 nF so as to not destabilize the opamp. f_low = 1/2/pi/R/C = 730 Hz.

I will do the swap later today unless someone else gets to it first. (note: check for oscillations w/ fast scope probe after installing)

I did these modification tonight. The slideshow of some images is attached. Instead of 100k, I used 97.6k thin film, since this seemed like an oddball size that doesn't get used otherwise. I forgot to measure the dark noise of the quadrants before doing the swap, but comparing the pit/yaw/sum before/after the swap shows that the signal is basically unchanged (since pit/yaw is normalized by SUM), but that the noise is lower by a factor of a few above 100 Hz due to being above ADC noise now. Previously, it was bottoming out at ~10 prad/rHz. Since the signal is unchanged, I guess that the calibration and therefore the loop gain should not have changed either...

And the sum went up by almost 10x as expected from the resistor change.

Anodized aluminum dumps replaced by 6 razor beam dumps.

Two more razor beam dumps added this afternoon.   The picture will updated tomorrow.

 Atm3, Oplev sum read 12,000 counts when the qpd was disconnected ?

           Dark qpd was zero and normal He/Ne incident on qpd was 1,730 counts.

[Rana, Jenne]

We have looked at a few things that do and don't affect the out of loop noise of the ALS X beat, and found that cavity alignment and beatnote RF frequency had the strongest effects.

Possible causes of noise:

1.  Air currents from A/C or flowbench.  No effect. 

        * When table lid is on, turning on and off the flow bench air did not qualitatively change the out of loop beatnote time series signal.

2.  Scattered light from other beams hitting green PDH PD.  No effect.

        * There are a few spots of green light that are hitting the case of the PDH photodiode, but when I put an iris in place to block those spots, there was no change in the beatnote spectra.  This makes sense to me since none of those spots were close to hitting the diode itself. 

        * Rana did notice that the beam was not well centered on the PD, so he steered the beam onto the center of the diode.  Also, the PD is now tilted a little bit so that the reflection from the diode doesn't go back into the beam path.  Neither of these things had an effect that we noticed in the beatnote noise.

3.  Oplev laser light getting to PDH PD.  Not tested.

       * We don't see any red light over by the PDH PD, so we did not try turning off the oplev's laser to see if that had an effect, but we suspect that it is not the cause of our noise.

4.  Clipping of main IR / green beam on Xend table.  Not tested.

      * We should still go have a look at this, but we no longer think that this is the main cause of the elevated noise.

5.  Scattered light all over Xend table.  Not tested.

     * We should still work on dumping extraneous beams on the table, but we do not think that this is the main cause of the elevated noise.

     * Rana took some photos so that we can see how truely bad the situation is.

6.  Amplitude modulation dip in NPRO.  Not tested.

    * It is probably still a good idea to check this, in case the dip in the amplitude modulation has changed over the year or two since it was last measured, but we also don't think that this is the main problem.

7.  Check PDH servo.  Not done.

     * I think this is still on Q's long-term todo list, but we should give the PDH servos a once-over.

8.  Arm cavity longitudinal motion.  No effect.

     * While the Xarm was locked with IR, we put a line at 1.7 Hz with 325 counts into the ITMX position.  To keep lock, the ETM had to move as well.  When we turned on this line (and increased its amplitude up to the final value of 325 cts), we did not see any qualitative change in the beatnote time series noise.

9.  Arm cavity alignment.  Significant DC effect.

    * When the alignment of one of the arm cavity mirrors is changed, the DC value of the beatnote signal changes. 

           * ITMX moved in yaw, we see a 7kHz/15urad DC shift in the BEATX_FINE_PHASE_OUT_HZ time series.

          * ETMX moved in yaw, we see an 8kHz/5.5urad DC shift in the time series.  We aren't sure why this is about a factor of 3 times larger effect (same shift for smaller misalignment) than the ITM.

    * We want to do a Yuta-style analysis to see what the angle to length coupling looks like, so that we can measure the angular motion of our cavity mirrors and put the expected noise into our ALS noise budget.  Perhaps this will help us understand the low frequency difference between our in-loop beatnote error signal and our in-loop PDH error signals (red vs. maroon on the ALS noise budget posted above Pianosa). 

    * I've asked Manasa to take some transfer functions in the morning, so that we can start to have an idea of what is going on with this.

10.  Beatnote RF frequency.  Significant broadband effect.

     * We have found that when the Xarm beatnote is at low RF frequencies, the noise is high, and when the beatnote is at high RF frequencies, the noise is low! 

     * Low RF freqs are below about 40 MHz, while high RF freqs are above about 90 MHz.  This has not been tested for the Yarm.  Also, these are for the case of "temp slider up, beatnote up".  I have not checked if the same is true for the other side of the PSL frequency, although I don't have reason to believe that it would be.

     * Maybe we are saturating some amplifiers?  We need to check this out.  One thought that Den mentioned was the harmonics, and that perhaps they are causing trouble in the electronics.

     * Den is going to think about implementing a frequency divider so that we can directly digitize the beatnote signal. 

    * Here are spectra for different cases:

        * And here is a spectrogram showing us going back and forth between the high and low noise states:

                     *  A:  First noticing that noise is good when RF frequency is high.

                     * B:  Not locked on TEM00 mode, so extra noisy.  Disregard.

                     * C:  Bad noise time.  Xbeat was 21 MHz (dark purple on DTT spectrum above), Ybeat was 118 MHz (sea green on DTT spectrum above).

                    * D:  Good noise time. Xbeat was 89 MHz (light purple on DTT plot), Ybeat was still 118MHz (turquoise on DTT plot).

                     * E:  Bad noise time.  Xbeat was 37.5 MHz, Ybeat was still 118 MHz.

                     * F:  Good noise time.  Xbeat was 113 MHz, Ybeat was still 118 MHz.

 Xend internal cabling and external connector is ready. We are waiting for seismometer from Gyro lab. We still need to fix the pot with clamps after we put the instrument in.

We also need a long cable from Xend to the guralp readout box.

15 hours

 The daytime crew had noticed that there were some ETMX angular shifts happening without any control or intention.

I reseated and strain relieved the bias cable coming into the backplane of the coil driver and now it seems OK.

In the 4-hour-long second trend plot below, the era before 2300 is before reseating. Afterwards, we make a couple adjustments, but so far there has been no un-asked for alignment shifts.

AdS has been run on both arms and offsets saved. Its locked on green/red and the beat frequencies are low and the amplitudes high. 

Sun May 18 23:53:37 2014: still OK...I declare it fixed.