I tried shifting the notch frequencies on the D000186-revision D board given to me by Koji. The existing notches were at ~16 kHz and ~32 kHz. I shifted these to notches at ~64 kHz and ~128 kHz by effecting the following changes (see schematic for component numbering) on Channel 8 of the board-I decided to check things out on one channel before implementing changes en masse:

• R6 and R7 replaced with 511 ohm smts
• R8 replaced with 255 ohm smt
• R14 and R15 replaced with 549 ohm smts
• R16 replaced with 274 ohm smt

=> New notches should be at 66.3 kHz and 131.7 kHz.

I then measured the frequency response of the modified channel using the SR785, and compared it to the response I had measured before switching out the resistors. The SR785 only goes up to 102 kHz, so I cannot verify the 128 kHz notch at this point. The position of the 64 kHz notch looks alright though. I think I will go ahead and switch out the remaining resistors in the evening.

Note 1: These plots are just raw data from the SR785, I have not tried to do any sort of fitting to poles and zeros. I will do this at some point. 

Note 2: All these smts were taken from Downs. Todd helped me locate the non-standard value resistors. I also got a plastic 25-pin D-sub backshells (the spares are in the rack), with which I have fashioned the required custom ribbon cables (40 pin IDC to 25 pin D-sub with twisted ribbon wire, and a short, 10pin IDC to 10pin IDC with straight ribbon wire).

Summary 

I have been working on setting up a QPD which can eventually be used to calibrate the PZT, and also orient the PZT in the mount such that the pitch and yaw axes roughly coincide with the vertical and horizontal.

The calibration constants have been determined to be:

X-axis: -3.69 V/mm

Y-axis: -3.70V/mm

Methodology:

I initially tried using the QPD setup left behind by Chloe near MC2, but this turned out to be dysfunctional. On opening out the QPD, I found that the internal circuitry had some issues (shorts in the wrong places etc.) Fortunately, Steve was able to hand me another working unit. For future reference, there are a bunch of old QPDs which I assume are functional in the cabinet marked 'Old PDs' along the Y-arm. 

I then made a circuit with which to read out the X and Y coordinates from the QPD. This consists of 4 buffer amplifiers (one for each quadrant), and 3 summing amplifiers (outputs are A+B+C+D = sum, B+C-A-D = Y-coordinate, and A+B-C-D = X-coordinate) that take the appropriate linear combinations of the 4 quadrants to output a voltage that may be calibrated against displacement of the QPD. 

The output from the QPD is via a sub-D connector on the side of the pomona box enclosing the PD and the circuitry, with 7 pins- 3 for power lines, and 4 for the 4 quadrants of the QPD. It was a little tricky to figure the pin-out for this connector, as there was no way to use continuity checking to map the pins to quadrants. Therefore, I used a laser pointer, and some trial and error (i.e. shine the light on a given quadrant, and check the sign of the X and Y voltages on an oscilloscope) to map the pin outs. Steve tells me that these QPDs were made long before colour code standardisation, but I note here the pin outs in any case for future reference (the quadrant orientations are w.r.t the QPD held with all the circuitry above it, with the active surface facing me):

Red= +Vcc

Black= -Vcc

Green = GND

Blue = Upper Left Quadrant

White = Upper Right Quadrant

Purple = Lower Left Quadrant

Grey = Lower Right Quadrant

Chloe had noted that there was some issue with the voltage regulators on her circuit (overheating) but I suspect this may have been due to the faulty internal circuitry. Also, she had used 12 V regulators. I checked the datasheet of the QPD, Op-Amp LF347 (inside the pomona box) and the OP27s on my circuit, and found that they all had absolute maximum ratings above 18V, so I used 15V voltage regulators. The overheating problem was not a problem anymore.

I then proceeded to arrange a set up for the calibration (initially on the optical bench next to MC2, but now relocated to the SP table, and a cart adjacent to it). It consists of the following:

• He-Ne laser source
• Y2 2-inch mirror (AR and HR coated for 532nm) glued onto the PZT and mounted on a machined Newport U100P  - see this elog for details.
• QPD mounted on a translational stage whose micrometers are calibrated in tenths of an inch (in the plots I have scaled this to mm)
• A neutral density filter (ND = 2.0) which I added so that the QPD amplifier output did not saturate. I considered using a lens as well to reduce the spot size on the QPD but found that after adding the ND filter, it was reasonably small.
• High-voltage power supply (on cart)
• Two SR power supplies (for the PZT driver board and my QPD amplifier
• SR function generator
• Laser power source
• Two oscilloscopes
• Breadboard holding my QPD amplifier circuit

Having set everything up and having done the coarse alignment using the mirror mount, I proceeded to calibrate the X and Y axes of the QPD using the translational stage. The steps I followed were:

• Centre spot on QPD using coarse adjustment on the mirror mount: I gauged this by monitoring the X and Y voltage outputs on an oscilloscope, and adjusted things till both these went to zero.
• Used the tilt knob on the translational stage to roughly decouple the X and Y motion of the QPD.
• Kept Y-coordinate fixed, took the X-coordinate to close to its maximum value (I gauged this by checking where the voltage stopped changing appreciably for changes in the QPD position.
• Using this as a starting point, I moved the QPD through its X range, noting voltage output of the X-coordinate (and also the Y) on an oscilloscope.
• Repeated the procedure for the Y-coordinate.
• Analysis follows largely what was done in these elogs. I am attaching the script I used to fit an error function to the datapoints, this is something MATLAB should seriously include in cftool (note that it is VERY sensitive to the initial guess. I had to do quite a bit of guessing).

The plots are attached, from which the calibration values cited above are deduced. The linear fits for the orthogonal axis were done using cftool. There is some residual coupling between the X and Y motions of the QPD, but I think this os okay my purposes. 

My next step would be to first tweak the orientation of the PZT in the mount while applying a small excitation to it in order to decouple the pitch and yaw motion as best as possible. Once this is done, I can go ahead and calibrate the angular motion of the PZT in mrad/V.

                                                            X-Axis                                                                                                                                Y-axis                                                

 Yesterday, I mounted the first PZT in one of the modified mounts, and then glued a 2-inch Y2 mirror on it using superglue.

Details:

-The mirror is a 2-inch, Y2 mirror with HR and AR coatings for 532 nm light.

-The AR side of the mirror had someone's fingerprint on it, which I removed (under Manasa's guidance) using tweezers wrapped in lens cleaning paper, and methanol.

-Before gluing the mirror, I had to assemble the modified mount. Manasa handed over the remaining parts of the mounts (which are now in my newly acquired tupperware box along with all the other Piezo-related hardware). I took the one labelled A, and assembled the holder part. I then used one of the new mounts (2.5 inches, these are with the clean mounts in a cardboard box in the cupboard holding the green optics along the Y-arm) and mounted the holder on it. 

-Having assembled the mount, I inserted the piezo tip-tilt into the holder. The wedge that the machine shop supplied is useful (indeed required) for this. 

-I then cleaned the AR surface of the mirror and the top-surface of the tip-tilt. 

-The gluing was done using superglue which Steve got from the bookstore (the remaining tube is in the small fridge). We may glue the other mirror using epoxy. I placed 4 small drops of superglue on the tip-tilt's top surface, placed the mirror with its AR face in contact with the piezo, and applied some pressure for a short while until the glue spread out fairly evenly. I then left the whole setup to dry for about half an hour.

-Steve suggested using a reference piece (I used two small bolts) to verify when the glue had dried.

-Finally, I attached the whole assembly to a base.

Here it is in action in my calibration setup (note that it has not been oriented yet. i.e. the two perpendicular axes of the piezo are for the time being arbitrarily oriented. And maybe the spreading of the glue wasn't that even after all...):

Sidenote:

Yesterday, while setting stuff up, I tested the piezo with a 0.05 Hz, 10Vpp input from the SR function generator just to see if it works, and also to verify that I had set up all my electronics correctly. Though the QPD was at this point calibrated, I did observe periodic motion of both the X and Y outputs of my QPD amp! Next step- calibration... 

 I carried some further modifications and tests to the AI Board. Details and observations here:

• I switched out the resistors for all the remaining 7 channels, using the same substitutions as detailed here. 
• I then verified that the modified transfer function for all 8 channels using the SR785. I did not collect data for all the channels as netgpib was taking ages, but I did use the cursor on the screen to verify the position of the first notch at ~64 kHz. I noticed that all the channels did not have the lowest point of the notch at the same frequency. Rather, (at least on the screen), this varied between 63kHz and 67kHz. I would put this down to component tolerance. Assuming 5% tolerance shifts the theoretical notch frequency from 66268 Hz to 63112 Hz. 
• After verifying the transfer functions, I went to 1Y4 and plugged the AI board into the eurocrate. I then connected the input of the AI board to the DAC output using my custom ribbon cable. Next, I used the excitation points set up earlier to send a 1 kHz, 32000 counts amplitude sine wave through the channels one at a time. I monitored the output using an oscilloscope and the LEMO monitor channels on the front panel of the board.
• I found that the single-ended output of the AI board swings between -10 V and 10 V (w.r.t ground, oscilloscope trace attached). This is good because this is the range of input voltage to the PZT driver boards required to realize the full actuation range of the PZTs.
• I also verified that the connections on the custom ribbon cable are correct (channel map was right) and that there were no accidental shorts (I checked other channels' output monitor while driving one channel). 

I think the board is okay to be used now.

 I have managed to orient the PZT in the mount such that its axes are approximately aligned with the vertical and the horizontal. 

In the process, I discovered that the 4 screws on the back face of the PZT correspond to the location of the piezoelectric stacks beneath the tip-tilt platform. The PZT can therefore be oriented during the mounting process itself, before the mirror is glued onto the tip-tilt platform.

In order to verify that the pitch and yaw motion of the mirror have indeed been roughly decoupled, I centred the spot on the QPD, fed to the 'pitch' input of the PZT driver board (connected to channel 1 of the PZT) a 10 Vpp, 1 Hz sine wave from the SR function generator (having turned all the other relevant electronics, HV power supply etc ON. The oscilloscope trace of the output observed on the QPD is shown. The residual fluctuation in the Y-coordinate (blue trace) is I believe due to the tilt in the QPD, and also due to the fact that the PZT isnt perfectly oriented in the mount.

It looks like moving the tip-tilt through its full range of motion takes us outside the linear regime of the QPD calibration. I may have to rethink the calibration setup to keep the spot on the QPD in the linear range if the full range is to be calibrated, possibly decrease the distance between the mirror and the QPD. Also, in the current orientation, CH1 on the PZT controls YAW motion, while CH2 controls pitch.

Oscilloscope Trace:

Yellow: X-coordinate

Blue: Y-coordinate

I mounted the second PZT in a modified mount, and then glued a 1-inch Y2 mirror on it using superglue.

 Details:

-The mirror is a Laseroptik 1-inch, Y2 mirror with HR and AR coatings for 532 nm light.

-The procedure for mounting the mirror was the same as detailed in elog 8874. This time, I tried to orient the Piezo such that the four screws on the back face coincided with the horizontal and vertical axes, as this appeared to (somewhat) decouple the pitch and yaw motion of the tip-tilt on the first PZT.

-One thing I forgot to mention in the earlier elog: it is best to assemble the mount fully before inserting the tip-tilt into it and gluing the mirror to the tip-tilt. In particular, the stand should be screwed onto the mount before inserting the tip-tilt into the holder, as once it is in, it will block the hole through which one can screw the stand onto the mount. 

 I recalibrated the QPD today as I had shifted its position a little. I then identified the linear range of the QPD and performed a preliminary calibration of the Piezo tip-tilt within this range.

Details:

-I recalibrated the QPD as I had shifted it around a little in order to see if I could move it to a position such that I could get the full dynamic range of the piezo tilt within the linear regime of the QPD. This proved difficult because there are two reflections from the mirror (seeing as it is AR coated for 532nm and I am using a red laser). At a larger separation, these diverge and the stray spot does not bother me. But it does become a problem when I move the QPD closer to the mirror (in an effort to cut down the range in which the spot on the QPD moves). In any case, I had moved the QPD till it was practically touching the mirror, and even then, could not get the spot motion over the full range of the PZTs motion to stay within the QPD's linear regime (as verified by applying a 20Vpp 1Hz sine wave to the PZT driver board and looking at the X and Y outputs from the QPD amplifier. 

-So I reverted to a configuration in which the QPD was ~40cm away from the mirror (measured using a measuring tape).

-The new calibration constants are as follows (see attached plots):

X-Coordinate: -3.43 V/mm
Y-Coordinate: -3.41 V/mm

-I then determined the linear range of the QPD to be when the output was in the range [-0.5V 0.5V]. 

-Next, at Jenne's suggestion, I decided to do a preliminary calibration of the PZT within this linear range. I used an SR function generator to supply an input voltage to the PZT driver board's input (connected to Channel 1 of the piezo). In order to supply a DC voltage, I set a DC offset, and set the signal amplitude to 0V. I then noted the X and Y-coordinate outputs, being sure to run through the input voltages in a cyclic fashion as one would expect some hysteresis. 

-I did this for both the pitch and yaw inputs, but have only superficially analysed the latter case (I will put up results for the former later). 

Comments:

-There is indeed some hysteresis, though the tilt seems to vary linearly with the input voltage. I have not yet included a calibration constant as I wish to perform this calibration over the entire dynamic range of the PZT. 

-There is some residual coupling between the pitch and yaw motion of the tip tilt, possibly due to its imperfect orientation in the holder (I have yet to account for the QPD's tilt).

-I have not included a graphical representation here, but there is significantly more pitch to yaw coupling when my input signal is applied to the tip-tilts pitch input (Channel 2), as compared to when it is input to channel 1. It is not clear to me why this is so.

-I have to think of some smart way of calibrating the PZT over its entire range of motion, keeping the spot in the QPD's linear regime throughout. One idea is to start at one extreme (say with input voltage -10V), and then perform the calibration, re-centering the spot to 0 on the QPD each time the QPD amp output reaches the end of its linear regime. I am not sure if this will work, but it is worth a shot. The other option is to replace the red laser with a green laser (from one of the laser pointers) in the hope that multiple reflections will be avoided from the mirror. Then I will have to recalibrate the set up, and see if I can get the QPD close enough to the mirror such that the spot stays within the linear regime of the QPD. More investigation needs to be done.

Plots:

QPD Calibration Plots:
            

Piezo tilt vs input voltage plots:

                                                          Yaw Tilt                                                                                                                                         Pitch Tilt

 In light of recent events and the decision to test the piezo tip-tilts for green beam steering on the X-end table, I have set up 8 excitation points to channels 8 through 15 of the DAC on c1scx (as was done earlier for the DAC at 1Y4 with Jenne's help) in order to verify that the pin-outs of the DAC interface board. I have not yet compiled the model or restarted the computer, and will do these tomorrow, after which I will do the test. The channels are named YYY_CHAN9 etc. 

 I just compiled and installed the model with the excitation points on c1scx and then restarted framebuilder. The channels I set up are now showing up in the awggui dropdown menu. I will do the tests on the DAC channels shortly.

Just to keep things on record, these are the steps I followed:

• opened the model c1scx (path: /opt/rtcds/userapps/release/sus/c1/models) with MATLAB
• Added 8 excitation points and saved the model. A copy has been saved as c1scx.mdl.r2010b because of the recent upgrade to r2013a. 
• ssh to c1iscex (computer running the model c1scx). 
• Entered the following sequence of commands in terminal: rtcds make c1scx ,  rtcds install c1scx , rtcds start c1scx 
• ssh to framebuilder, and restarted the framebuilder by entering telnet fb 8088   and then   shutdown.

 I just finished carrying out the same checks for the DAC at 1X9 (with channels 9 through 16 that are unused as of now) as those I had done for the DAC at 1Y4, as the hardware prep up till now was done with the characterisation of the DAC at 1Y4. Conclusions:

• The accessible range of output voltage are -10 V to +10V w.r.t ground --> No change needs to be made to the gain of the HV amplifier stage on the PZT Driver Board
• The pin-outs of the DAC Adaptor Board at 1X9 is identical to that at 1Y4 --> Custom ribbons do not need to be modified.
• The PSD of the DAC output has a peak at 64 kHz --> Notches on AI Board do not need to be moved again.

I will now proceed to install various pieces of hardware (AI Board, PZT driver board, HV Power Supply and cabling) at 1X9, while not making the connection to the PZTs till I receive the go ahead. 

 Given that the green beam is to be used as the reference during the vent, it was decided to first test the PZT mounted mirrors at the X-endtable rather than the Y-endtable as originally planned. Yesterday, I prepared a second PZT mounted mirror, completed the full range calibration, and with Manasa, installed the mirrors on the X-endtable as mentioned in this elog. The calibration constants have been determined to be (see attached plots for aproximate range of actuation):

M1-pitch: 0.1106 mrad/V

M1-yaw: 0.143 mrad/V

M2-pitch: 0.197 mrad/V

M2-yaw: 0.27 mrad/V

Second 2-inch mirror glued to tip-tilt and mounted:

• The spot sizes on the steering mirrors at the X-end are fairly large, and so two 2-inch steering mirrors were required.
• The mirrors already glued to the PZTs were a CVI 2-inch and a Laseroptik 1-inch mirror.
• I prepared another Laseroptik 2-inch mirror (45 degree with HR and AR coatings for 532 nm) and glued it to a PZT mounted in a modified mount as before.
• Another important point regarding mounting the PZTs: there are two perforated rings (see attached picture) that run around the PZT about 1cm below the surface on which the mirror is to be glued. The PZT has to be pushed in through the mount till these are clear of the mount, or the actuation will not be as desired. In the first CVI 2-inch mirror, this was not the the case, which probably explains the unexpectedly large pitch-yaw coupling that was observed during the calibration [Thanks Manasa for pointing this out]. 

Full range calibration of PZT:

Having prepared the two steering mirrors, I calibrated them for the full range of input voltages, to get a rough idea of whether the tilt varied linearly and also the range of actuation. 

Methodology:

• The QPD setup described in my previous elogs was used for this calibration. 
• The linear range of the QPD was gauged to be while the output voltage lay between -0.5V and 0.5V. The calibration constants are as determined during the QPD calibration, details of which are here.
• In order to keep the spot always in the linear range of the QPD, I stared with an input signal of -10V or +10V (ie. one extreme), and moved both the X and Y micrometers on the translational stage till both these coordinates were at one end of the linear range (i.e -0.5V or 0.5V). I then increased the input voltage in steps of ~1V through the full range from -10V to +10V DC. The signal was applied using a SR function generator with the signal amplitude kept to 0, and a DC offset in the range -5V to 5V DC, which gave the desired input voltages to the PZT driver board (between -10V DC and 10V DC).
• When the output of the QPD amp reached the end of the linear regime (i.e 0.5V or -0.5V), I moved the appropriate micrometer dial on the translational stage to take it to the other end of the linear range, before continuing with the measurements. The distance moved was noted. 
• Both the X and Y coordinates were noted in order to investigate pitch-yaw coupling.

Analysis and remarks:

• The results of the calibration are presented in the plots below. 
• Though the measurement technique was crude (and maybe flawed because of a possible z-displacement while moving the translational stage), the calibration was meant to be rough, and I think the results obtained are satisfactory. 
• Fitting the data linearly is only an approximation, as there is evidence of hysteresis. Also, PZTs appear to have some drift, though I have not been able to quantify this (I did observe that the output of the QPD amp shifted by an amount equal to ~0.05mm while I left the setup standing for an hour or so).  
• The range of actuation seems to be different for the two PZTs, and also for each degree of freedom, though the measured data is consistent with the minimum range given in the datasheet (3.5 mrad for input voltages in the range -20V to 120V DC). 

PZT Calibration Plots

The circles are datapoints for the degree of freedom to which the input is applied, while the 'x's are for the other degree of freedom. Different colours correspond to data measured with the position of the translational stage at some value.

                                            M1 Pitch                                                                                             M1 Yaw

                                              M2 Pitch                                                                                        M2 Yaw 

Installation of the mirrors at the X-endtable:

The calibrated mirrors were taken to the X-endtable for installation. The steering mirrors in place were swapped out for the PZT mounted pair. Manasa managed (after considerable tweaking) to mode-match the green beam to the cavity with the new steering mirror configuration. In order to fine tune the alignment, Koji moved ITMx and ETMx in pitch and yaw so as to maximise green TRX. We then got an idea of which way the input pointing had to be moved in order to maximise the green transmission.

I have updated the schematic of the D980323 PZT driver boards to reflect the changes made. The following changes were made (highlighted in red on the schematic):

• Gain of all four HV amplifier stages changed from ~15 to ~5 by swapping 158k resistors R43, R44, R69 and R70 for 51k resistors.
• Electrolytic 10 uF capacitors C11, C12, C29 and C31 swapped for 470pF, 500V mica capacitors.
• Fixed resistor in voltage divider (R35, R40, R59 and R64) replaced with 0 ohm resistors so as to be able to apply a bias of -10V to the HV amplifier
• The DC-DC Series components, which I think were originally meant to provide the 100V DC voltage, have been removed.
• The path between the point at which +100V DC is delivered and jumpers J3 and J6 has been shorted (bypassing R71 and R11 for J3, R73 and R12 for J6).
• Tantalum capacitors C38 and C39 have been replaced with electrolytic capacitors (47 uF, 25V). One of the original tantalum capacitors had burned out when I tried installing the board in the eurocrate, shorting out -15V to ground. At Koji's suggestion, I made this switch. The AD797s do not seem to be oscillating after the switch.
  
  
  

I have also changed the routing of the 100V from the HV power supply onto the board, it is now done using an SMA T-connector and two short lengths of RG58 cable with SMA connectors crimped on.

The boards are functional (output swings between 0 and 100V as verified with a multimeter for input voltages in the range -10V to +10V applied using a function generator.

Revised schematics:

 The following hardware has been installed on rack 1X9;

• KEPCO high voltage power supply (kept in a plastic box at the bottom of the rack, with the 3m SMA cable carrying 100V running along the inside side wall of the rack). The HV supply has not been connected to the driver board yet.
• AI board D000186 installed in top eurocrate. The board does not seem to fit snugly into the slot, so I used a longish screw to bolt the front panel to the eurocrate.
• PZT driver board D980323 installed in top eurocrate adjacent to the AI board.
• Six 11m SMB-LEMO cables have been laid out from 1X9 to the endtable. I have connected these to the PZT driver board, but the other end (to the PZTs) is left unconnected for now. They have been routed through the top of the rack, and along the cable tray to the endtable. All the cables have been labelled at both ends. 
  

I have also verified that the AI board is functional in the eurocrate by using the LEMO monitoring points on the front panel.

The driver boards remain to be verified, but this cannot be done until we connect the HV supply to the board. 

 [Alex, Gautam]

The signal chain from the DAC output to the output of the PZT driver board (including the HV supply) has been verified. 

I had installed the two boards in the eurocrate yesterday and laid out the cables from 1X9 to the endtable. The output of the AI board had been verified using the monitor port on the front panel, but the output from the PZT driver board was yet to be checked because I had not connected the HV supply yesterday.

When I tried this initially today, I was not getting the expected output from the monitor channels on the front panel of the PZT driver board, even though the board was verified to be working. Alex helped debug the problem, which was identified as the -15V supply voltage not making it onto the board.

I changed the slot the board was sitting in, and used a long screw to bolt the board to the crate. Both the AI board and the PZT driver board seem to be slightly odd-sized, and hence, will not work unless firmly pushed into the eurocrate and bolted down. This would be the first thing to check if a problem is detected with this system. 

In any case, I have bolted both boards to the eurocrate, and the output from the PZT driver board is as expected when I sent a 10Vp sine wave out from the DAC. I think the cables can now be hooked up to the PZTs once we are pumped down.

 I have glued a fourth mirror to a PZT (using superglue) and inserted it into a modified mount. This is to be used together with the 1-inch Laseroptik mirror I had glued a couple of weeks back at the Y-endtable. I will be calibrating both these mirrors tonight such that these are ready to put in as soon as we are pumped down.

The mirror was one of those removed from the X-endtable during the switch of the steering mirrors. It is a CVI 2-inch mirror, with HR and AR coatings for 532 nm. 

I have made a new model for the endtable PZT servo, and have put it in c1iscex. Model name is c1asx. Yesterday, Koji helped me start the model up. The model seems to be running fine now (there were some problems initially, I will post a more detailed elog about this in a bit) but some channels, which are computer generated, don't seem to exist (they show up as white blocks on the MEDM GDS_TP screen). I am attaching a screenshot of the said screen and the names of the channels. More detailed elog about what was done in making the model to follow.

Channel Names:

C1:DAQ-DC0_C1ASX_STATUS (this is the channel name for the two leftmost white blocks)

C1:DAQ_DC0_C1ASX_CRC_CPS

C1:DAQ-DC0_C1ASX_CRC_SUM

 These are roughly the steps I followed in setting up the new model for the endtable PZT servo - C1ASX.

Simulink model:

I made a SIMULINK model of the servo, using MATLAB R2013a. The path to the model is /opt/rtcds/caltech/c1/userapps/release/isc/c1/models/c1asx.mdl. I am listing the parameters set on the CDS_PARAMETERS block:

• host = c1iscex
• site = c1
• rate = 16k
• dcuid = 44 (which I chose after making sure that this dcuid was not used on this list which was last updated end Feb 2013)
• specific_cpu = 5 (again chosen after checking the available CPUs in the above list).
• adc_Slave = 1
• shmem_daq = 1
• no_rfm_dma = 1
• biquad = 1

Making, Compiling and Installing the Model:

After saving the model, I ssh-ed into c1iscex and ran the following commands:

rtcds make c1asx - this gave me a whole bunch of errors initially, which I tracked down to a naming problem in some of the from and goto flags: there should not be any spaces.

rtcds install c1asx 

rtcds start c1asx - this gave me an error which said something like 'can't start/stop model.' Koji pointed out that given that a new model is being started, there is an additional step involved, which is to add the model name to the rtsystab file (this is located at /diskless/root/etc/rtsystab on framebuilder, and is mirrored in the various computers. It would be advisable to make sure that the changes are mirrored in the corresponding file on the computer in which the new model is being installed). 

After adding the model name to the rtsystab file, I tried running rtcds start c1asx again. This time, no errors were output, but the model was not up and running as verified by looking at the C1:ASX_GDS_TP medm screen.

 Debugging 

Koji suggested making a simple model (1 CDS parameters block, 1 ADC block and 2 filter modules, appropriately terminated) and see if that starts up, which it did. I then tried adding my servo minus the DAC block and recompiled and restarted the model. This too worked fine. I figured that the next logical step would be to add the DAC block to the model, and restart the model. But when I tried this, c1iscex crashed .

Jenne helped in restoring things to a working state (we reverted the c1asx model to just 2 filter modules, and went to the X-end and restarted the computer. This did not work the first time so I went back in and restarted it again, at which point we were able to ssh into c1iscex again and restart the four models running on it).

Since Manasa and Koji were working on getting things set up for the pumpdown,I did not try anything again till later in the evening, when Koji helped in debugging the problem further. In the meantime, at Jenne' suggestion, I made the model once again in MATLAB R2010b. In the evening, when I tried restarting the model, Koji suggested that the DAC channels in c1asx may be used by other models, at which point I realised I had set up excitation points on channels 8 through 15 of the DAC in c1scx (detailed here) in order to test the hardware at 1X9. I removed the excitation points from channels 8-11 of the DAC block in c1scx (these are the ones used in c1asx), and recompiled and restarted c1asx (using the above sequence of commands). I then tried recompiling and starting c1asx once more, and this time, it worked . At least, the GDS_TP screen suggests that the model is running alright, except for the fact that some computer generated channels seem to be missing. This problem is unresolved for now, and probably has something to do with the fact that C1ASX channels do not appear in Dataviewer.

I do not think this has to do with restarting framebuilder (I did the usual telnel fb 8088 followed by shutdown). In any case, I have added the new model to the CDS_FE_STATUS screen, and will continue to debug the same. I have also got a template medm screen (work in progress) which I will elog about soon as I get it done.

Note to self: There are 4 more excitation channels still hooked up to the DAC (channels 12-15) in the c1scx model. I plan to remove these and put them in c1asx.

Koji just fixed this.

It seems that the new model's channels were not automatically added to the master file in the framebuilder (/opt/rtcds/caltech/c1/target/master). Adding the following two lines to the master file fixed the problem;

/opt/rtcds/caltech/c1/chans/daq/C1ASX.ini

/opt/rtcds/caltech/c1/target/gds/param/tpchn_c1asx.par

The box is now green. It looks like C1ASX.ini is created automatically in /opt/rtcds/caltech/c1/chans but the master file needs to be manually edited. The channels are now showing up on dataviewer etc. I have updated the information on the wiki page.

I have made some minor changes to the model, made all the MEDM screens, and linked monitors on these to the appropriate channels. I have borrowed heavily from the C1ASS MEDM screens (particularly for the small filter modules-it was convenient to just copy and paste an existing module, and edit the channel names using EMACS/GEDIT), and have edited these to suit the needs of this servo. Some features:

• The feedback signal (only the output of the servo to the PZTs, plus any contribution from the on-screen sliders, and not including the LO output) is monitored with both a slow (using CDS_EPICS_OUTPUT block from the CDS_PARTS library) and fast channel (using Test Point from the same library). The idea is that it would be useful to know the output to the PZTs such that if coarse adjustment ever needs to be done at the endtable, the PZTs can be restored to the middle of its operating range by means of the sliders.
• Sliders are incorporated into the master screen for adjusting the output to the PZTs. There are text-input fields below the sliders as well, which control the same channel.
• I have removed the 4 remaining excitation points to the DAC set up in C1SCX, and have relocated them to channels 12-15 of the DAC in C1ASX.

I think I am now ready to take some measurements and try and optimize this servo. There is no green transmission at the PSL table at the moment, so not much can be done, though the first step would be to take the power spectrum of the error signal, which would help me decide the appropriate frequencies for the LOs. I would then have to add the appropriate filters to the model. The last, and most difficult step, would be the measurement of the output matrix, though Koji has given me some ideas about how this measurement can be done. I also have a template script ready, though I will only finalise this after optimising the servo and running it a couple of times manually.

Attached are screenshots of the MEDM screens.

The following slow channels have been added and are now being recorded by FB.

C1:ALS-X_OVEN_TEMP

C1:ALS-Y_OVEN_TEMP

C1:ALS-BEATX_FREQ

C1:ALS-BEATY_FREQ

Details:

In order to integrate the data collected by the Raspberry-Pi from the Y-end doubling oven temperature controller and also the data from the frequency counter which will be hooked up to monitor the beat frequency, Koji helped me set up some slow EPICS record channels (in ALS as we felt this was most appropriate). The procedure for setting up slow channels was as follows (virtually identical to what is detailed in this elog:

1. Add the channel names to the file C0EDCU.ini (path = /opt/rtcds/caltech/c1/chans/daq/C0EDCU.ini).
2. Make a database (.db) file so that these channels are actually recorded (path = /cvs/cds/caltech/target/c1aux/als.db).
3. Restart framebuilder. 
4. Verify that the channels indeed exist and can be read and written to using ezcaread and ezcawrite.

I will now integrate these channels into my scripts, and make some simple MEDM screens.

In order to decide what frequencies to dither the 4 degrees of freedom (M1-pitch&yaw, M2-pitch&yaw) at, I took the power spectrum of the X and Y-arm green transmission (C1:ALS-TRX_OUT, C1:ALS-TRY_OUT). Plots showing the power spectra are attached. Looking at the power spectra, I would think that for the X-arm, it would be okay to dither at 40, 50, 60 and 70 Hz. In order to check if the piezos could respond to these frequencies, I used my QPD setup and shook the PZTs with a 100Hz, 1Vpp sinusoid, and saw that the spot moved smoothly on the QPD.

 As for choosing the modulation amplitude, I did a simplistic approximation assuming that the misalignment only rotates the beam axis relative to the cavity axis, and determined what angle coupled 10% of the power into the next eigenmode. Assuming that this is small enough such that if we are already locked to TEM00, the dither won't kick it up to some higher-order mode, the LO amplitude should be in the range of 30-60 digital counts (determined using the PZT calibration constants determined here. This corresponds to a sine-wave of ~50mV amplitude reaching the PZTs (after HV amplification). I am not sure if this is too small, but according to the PZT datasheet, these platforms are supposed to have a resolution of 0.02 urad, which would correspond to the input signal changing by ~0.1 mV, so this signal should be capable of dithering the tip-tilt. 

 I have already added band-pass filters centered at these frequencies to the model (with a passband of 5Hz, 2Hz on either side), and low-pass filters to pull out the DC component of the output of the lock-in amplifiers. It remains to tune the gains of the filter stages. These parameters (frequency, amplitude of the LOs) may also have to be changed after tests). Hopefully the PZTs can be plugged in tomorrow, and I can try and make a measurement of the output matrix. 

Koji also suggested that it may be good to have a path in the model that feeds back to the PZTs by dithering the cavity mirrors as opposed to the PZT mounted mirrors. I will work on incorporating this into the SIMULINK model (c1asx.mdl) and also into the master medm screen.

Notes:

1. The spot size of the X-arm green transmission on the PD was larger than the active surface. I moved the GTRX PD a little back and put in a lens (KPX085, 62.9mm FL, AR.14) in front of the PD, such that the spot is now occupying about 1/4th of the active surface area. The lens was mounted in a Thorlabs LMR1mount, and has been labelled.
2. I made a slight change to the SIMULINK model, so as to calibrate the PZT sliders to (approximately) volts (I added a multiplier block that multiplies the slider value by constant value 3267.8). The idea is that we can approximately relate the slider value to tilt, knowing the calibration constant in mrad/V for the PZTs.

Power Spectra of Arm Green Transmission:

 I had prepared two more PZT mounted mirrors for the Y-end some time back. These are:

• A 2-inch CVI mirror (45 degree, HR and AR for 532nm, was originally one of the steering mirrors at the X-endtable, and was removed while switching those out for the PZT mounted mirrrors).
• A 1-inch Laseroptik mirror (45 degree, HR and AR for 532nm).

I used the same QPD set-up and the methodology described here to do a full-range calibration of these PZTs. Plots attached. The calibration constants have been determined to be:

CVI-pitch: 0.316 mrad/V

CVI-yaw:  0.4018 mrad/V

Laseroptik pitch: 0.2447 mrad/V

Laseroptik yaw:  0.2822 mrad/V

Remarks:

• These PZTs, like their X-end counterparts, showed evidence of drift and hysteresis. We just have to deal with this.
• One of the PZTs (the one on which the CVI mirror is mounted) is a used one. While testing it, I thought that its behaviour was a little anomalous, but the plots do not seem to suggest that anything is amiss.

Plots:

                                                        CVI YAW                                                                                                                         CVI PITCH

                                                        Laseroptik YAW                                                                                                             Laseroptik PITCH

   

I redid the power spectrum measurement for the X-arm green transmission after aligning the arm to green using the ITMX/ETMX Pitch and Yaw sliders on IFOalign.

The Y-axis now reflects the relative intensity noise (RIN), which I obtained by taking the average value of the X-arm green transmission using tdsavg. Based on this measurement, I have now picked four new frequencies at which to try and modulate the PZT mirrors: 10, 19, 34 and 39 Hz. Bandpass filters in the LIA stage have been appropriately modified. 

Power Spectrum:

 I have done some preliminary testing of the X-End Green ASS Servo. I will write a more detailed elog about this soon, but I thought I'd note down the important stuff here.

Yesterday, while we were venting, I aligned the X-arm to the green using the sliders on IFOalign, maximizing the transmission. Then I retook a power spectrum so as to determine the LO frequencies. Jenne pointed out that LO frequencies should not be integers (it usually suffices to append a .098725 or something to the frequency) so I made the necessary changes.

I did a first run of the servo yesterday, and more runs today. Notable points:

1. I was able to lock to 00 from a 08 or 09 mode using the PZT sliders
2. The green transmission having locked to 00 was ~0.2. I then ran the servo and got it up to ~0.4 and then 0.6 (see time series plot attached). The servo was able to recover this level of transmission after misaligning the steering mirrors using the PZT sliders.
3. This was not the optimal transmission level as when Koji moved ETMX a little, the transmission improved.
4. The actuators are degenerate. Most of the time, only two of the four servos are doing anything significant. This is probably because of the fact that the two steering mirrors are so close to each other, that moving one or the other produces virtually the same effect. I do however have some cool videos of mode-hopping :)
5. The range of actuation of the PZTs is probably not enough to maximize the green transmission from an arbitrary state because of point 4 (i.e. we need to move one mirror in some direction a lot, and move the other a lot to compensate for the change, and the overall gain in input pointing/alignment is marginal). It may be that things will be slightly better at the Y-end. It would also be interesting to see if there is any improvement in the servo performance by dithering the cavity mirrors as opposed to the PZT mirrors.
6. To this end, I tried modifying the c1asx model to incorporate an option to dither the cavity mirrors. The plan was to make a second set of LOs in the model that output to ITMX and ETMX suspensions. However, for some reason, when I recompiled the model and restarted it, c1iscex crashed. Parity has now been restored. Note that in order to accommodate the new LOs, I had to make changes to C1SUS, C1RFM and C1SCX as well. I have since removed all my additions, saved, built and installed these models, but have not restarted them (with the exception of C1SCX which restarted when I manually restarted c1iscex). 
7. The plan tomorrow is to try incorporating cavity dither into the model again. This time, I'll try grabbing the LO-related signals from c1ass directly, as I am not clear why my approach did not work.

More details to follow.

Over the last three days, I've had the interferometer to test and optimize the ASX Servo. Based on what I have seen, I think the conclusion is that with the current parameters, the servo does its job provided the input pointing set up at the endtable with the coarse adjustment knobs is reasonably good. Once the cavity is aligned and IR transmission maximized using ASS, I have been able to get the green transmission up to 0.8 which is close to the best we had pre-vent. I have not been elogging regularly over the last few days, so this one is going to be a longish one.

Major changes made:

1. The SIMULINK model has been modified to accommodate an option to dither the cavity mirrors and not the PZT mirrors. Details are as follows:
   • I have sent the LO signals (CLK,SIN and COS) from the ASS model to the ASX model via the RFM model. Appropriate changes were made to all these three models, and recompiling and restarting the models was done without issue. The SIN and COS signals are used to demodulate green transmission at the dither frequencies. ***The CLK signal is not required to be sent between models as it is not being used by ASX (I turn the dither ON using the channels already set up for ASS). I realised this a little late, and at present the ASS and RFM models are compiled such that the CLK signal is also sent from ASS to RFM. This can be removed, thus freeing up 4 unnecessary inter-process communication channels. Also, I am not too sure if this is relevant, but the maximum computation time of both the RFM and ASX models seem to have gone up after I added these inter-process communication links.***
   • The rest of this part of the servo is a replica of the part where PZT mirrors are dithered. At present the servo output is the sum of its two branches (PZT mirror dither branch and cavity mirror dither branch) which works fine under the assumption that at any one time, only one arm will run. Ideally, the summing block should be replaced by a switch. However, when I tried (in an earlier attempt to include the cavity dither) to do this and restart the model, c1iscex crashed, and so I decided against using the switch block for this trial.
   • The control signal generated using green transmission demodulated at the ETM dither frequencies are used to actuate on M1 while the ITM ones are used to actuate on M2. Of course, by setting the appropriate off-diagonal elements in the output matrix, this can be modified as desired.
2. The main MEDM screen has been updated to reflect the new additions to the SIMULINK model. Screenshot is attached. The picture isn't entirely accurate as the monitor channels in the upper row actually show the servo output + slider output. This needs to be changed in the model, and a new set of monitors need to be added to the MEDM screen. In the end, we require four sets of monitor-points in the model: PZT dither servo output, cavity dither servo output, sum of these with any offset from the PZT sliders, and the sum of the latter with the dither signal (this is what eventually goes to the PZT mirrors while the dither is on).
3. I added scripts to the MEDM screen that turn the PZT mirror dither servo on and off. Note that when you want to run a new script on an MEDM screen using medmrun, you need to change the permissions of the file by going to the path where your script is located and running chmod 755 <name of script>. Manasa has updated the same on the wiki.

 Details of tests runs:

For the most part, I have been trying to optimize the PZT mirror dither servo. To this end, I did the following:

• Went to the X-end and fixed the input pointing which was not optimal. Manasa first aligned the arm and ran ASS to maximize the IR transmission. I then used the coarse adjustment knobs on the mirror mounts to get the green transmission up to ~0.6.
• I then set the following parameters in the servo (these are all in the script, path to which is /opt/rtcds/caltech/c1/scripts/ASX):
  1. LO frequencies of 10, 19, 34 and 39 Hz respectively for M1 PIT, M1 YAW, M2 PIT and M2 YAW.
  2. LO amplitudes of 75 for all the four degrees of freedom (determined by using PZT calibration to see what amplitude would couple 10% of power into the first higher-order-mode assuming a perfectly aligned beam to start with.
  3. LIA BP filters centered at the above frequencies with 2Hz passband on either side.
  4. LIA LP filters with corner frequency 0.5 Hz.
  5. LIA Signal filter bank gain set to 100 for all degrees of freedom.
  6. LIA Demod I phase filter bank gain set to 5 for all degrees of freedom.
  7. Control filter gains to 1 for all degrees of freedom (control filters are all integrators).
  8. Demod phase set to 0 for all degrees of freedom. I did not really try to optimize this but the servo seems to be doing reasonably well even with this setting.
  9. Overall servo gain to 1 (the servo worked well when I increased this to 5 as well, but became unstable when I increased it further).
• I ran the servo. Observations were as follows:
  
  • Having fixed the input pointing to get green transmission up to ~0.6, the servo was able to improve it to ~0.8, which is the best we had after hours spent at the X-end prior to the vent.
  • Given a good input pointing, we can use the PZT mirrors to lock to 00 mode from some misaligned state using either the sliders, or by leaving the servo on, and helping it out at the points where it gets 'stuck' in some higher mode using either the sliders or by toggling the shutter.
  • In order to recover green transmission of ~0.8, it was often necessary to first run ASS to optimize the IR transmission. Otherwise, green-transmission saturates at ~0.6 or 0.4 depending on the misalignment of the arm cavity mirrors. The servo was unable to change the input pointing enough to deal with overly misaligned cavity mirrors. 
  • The servo is sometimes capable of bringing about mode-hopping from a higher order mode to a lower one, though this is not always the case as the PDH lock is sometimes too strong, in which case I toggled the shutter after which the servo kicked in.
  • I tested the servo under as many different conditions as I could. For instance, having left the green shutter open overnight, I saw that the transmission had fallen from 0.8 (which was what we saw on Thursday night) to ~0.4 on Friday morning. Running the servo got the transmission up to 0.6. I then asked Manasa to run ASS, (while leaving the ASX servo on), after which point the green transmission went up to 0.8. Sometimes, the servo locks to a 'bad' 00 mdoe, where the transmission saturates at ~0.2, but toggling the shutter fixes this most of the time.

Attempt to measure transfer function:

One of the things that came up during my presentation was how fast the loop was capable of responding. I was able to get a quantitative idea of this by playing around with the overall servo gain. Initially, it took ~30 seconds for the servo to get the transmission up to its peak value, with a servo gain of 1. When I ramped this up to 5, the response was much faster, with the peak transmission being reached in ~5seconds. 

I wanted to get a more quantitative picture, and hence tried to measure the transfer function by first injecting an excitation into the 'SIG' filter-bank in the demodulation stage. However, coherence between the IN1 and IN2 signals was very poor for all the amplitude configurations I tried. At Jenne's suggestion, I tried injecting the excitation at the control-filters stage, but found no improvement. Perhaps the amplitude envelope was wrong or the measurement technique has to be rethought. 

 Misc remarks:

1. M1 is the first steering mirror and M2 is the second one (right before the beam enters the arm cavity).
2. Though I have added the cavity dither feature to the model, I was not able to optimize this servo. Some calculations need to be done to get an estimate of the output matrix, after which the filter gains etc can be optimized.
3. Today, I cleaned up my temporary setup at the SP table to calibrate the PZTs. Most of the hardware for the Y-end is now in the tupperware box. The QPD and laser have been restored to the optical bench next to MC2 where I found them. The second KEPCO HV supply which I had set up has now been installed at 1Y4 in anticipation of the PZT mirrors at the Y-endtables. It is currently powered OFF.
4. Performance plots to follow as I have not pulled the data out yet.
5. I had bought a cake from chandler today in an effort to clear my meal plan, but in the rush in the afternoon, completely forgot about it. It is in the fridge, and is strawberry tart, hope it tastes good.

 New MEDM screen:

[Steve, gautam]

We fixed the problematic DIN connectors on 1Y2, by swapping out the 3 DIN connector blocks that were of the wrong type (see attached image for the difference between the types appropriate for "Live" and "Ground").

Before doing anything, Eric turned the Wenzel multiplier off. We have not turned this back on.

Then we turned off the power supply unit at the base of 1Y2, removed the connectors from the rail, swapped out the connectors, reinstalled them on the rail, and turned the power supply back on. After swapping these out, we verified with a multimeter that between each pair of "Live" and "Ground" blocks, there was ~15V. We could now use the third unused pair of blocks to power the delay line phase shifter box, though for the moment, it remains powered by the bench power supply. 

I made some changes to the c1tst model running on c1iscey in order to test my algorithm for frequency counting. I followed the steps listed in elog 8909 to make, install and start the model. 

I need to debug a few things and run some more diagnostics so I am leaving the model in its edited version (Eric had committed it to the svn before I made any changes). 

I have been working on setting up a frequency counting module that can give us a readout of the beat frequency, divided by a factor of 2^14 using the Wenzel frequency dividers as described here. This is a summary of what I have thus far.

The algorithm, and simulink model

The basic idea is to pass the digitized signal through a Schmitt trigger (existing RCG module), which provides some noise immunity, and should in theory output a clean square wave with the same frequency as the input. The output of the Schmitt trigger module is either 0 (for input < lower threshold value) and 1 (for input greater than the high threshold value). By differencing this between successive samples, we can detect a "zero-crossing", and by measuring the time interval between successive zero crossings, we can take the reciprocal to get the frequency. The last bit of this operation (i.e. measuring the interval) is done using a piece of custom C code. Initially, I was trying to use the part "GPS" from CDS_PARTS to get the current GPS time and hence measure intervals between successive zero-crossings, but this didn't work out because the output of GPS is in seconds, and that doesn't give me the required precision to count frequency. I tried implementing some more precision timing using the clock_gettime() function, which is capable of giving nanosecond precision, but this didn't work for me. So I am now using a more crude way of measuring the interval, by using a counter variable that is incremented each time a zero-crossing is NOT detected, and then converting this to time using the FE_RATE macro (=16384). In any case, the ADC sampling rate limits the resolution of frequency counting using zero-crossing detection (more on this later). Attachment 1 shows the SIMULINK block diagram for this entire procedure.

Testing the model

I implemented all of this on c1tst, and followed the steps listed here to get the model up and running. I then used one of the DB37 breakout boards to send a signal to the ADC using the DS345 function generator. Attachment 2 shows some diagnostic plots - input signal was a 2.5Vpp (chosen to match the output from the Wenzel dividers) square wave at 2kHz:

• Bottom left: digitized version of the input signal - I used this to set the upper and lower thresholds on the Schmitt trigger at +1000 counts and -1000 counts respectively.
• Top left: Schmitt trigger output (red trace) and the difference between successive samples of the Schmitt trigger output (blue trace - this variable is used to detect a zero crossing)
• Top right: Counter variable used to measure intervals between successive zero crossings, and hence, the frequency. The frequency output is held until the next zero crossing is detected, at which time counter is reset
• Bottom right: frequency output in Hz.

The right column pointed me to the limitations of frequency counting using this method - even though the input frequency was constant (2kHz), the counter variable, and hence the frequency readout, was neither accurate nor precise. But this was to be expected given the limitations imposed by ADC sampling? We only get information of the state of the input signal once within each sampling interval, and hence, we cannot know if a zero crossing has occurred until the next sampling interval. Moreover, we can only count frequency in discrete steps. In attachments 3 and 4, I've plotted these discrete frequencies which can be measured - the error bars indicate the error in the frequency readout if the counter variable is 1 more or less than the "true" value - this can (and does) happen if the high and low times of the Schmitt trigger are not equal over time (see top left plot in Attachment 2, its not very obvious, but all the "low" times are not equal, and so, the interval between detected zero crossings is not equal). This becomes a problem for small values of the counter variable, i.e. at high input frequencies. I was having a look at the elogs Aidan wrote some years ago for a different digital frequency counting approach, and I guess the conclusion there was similar - for high input frequencies, the error is large. 

I further did two frequency sweeps using the DS345, to see if I could recover this in the frequency readout. Attachments 5 and 6 show the results of these sweeps. For low frequencies, i.e. 100-500 Hz, the jitter in the readout is small (though this will be multiplied by a factor of 2^14), but by the time the input frequency gets up to 2kHz, the jitter in the readout is pretty bad (and gets worse for even higher frequencies.

Bottom line

Some refinements can be made to the algorithm, perhaps by introducing some averaging (i.e. not reading out frequency for every pair of zero crossings, but every 5) which may improve the jitter in the readout, but I would think that the current approach is not very useful above 2kHz (corresponding to ~30MHz of pre-divider frequency), because of the limitations shown in attachments 3 and 4. 

Earlier today, the front panels for the 1U chassis I obtained to house the Wenzel dividers + RF amplifiers arrived, which meant that finally I had everything needed to complete the assembly. Pictures of the finished arrangement attached. 

Summary of the arrangement:

• Two identical channels (RF amplifier + /64 divider + /256 divider), one for each arm
• The front panels are anodized, and isolated SMA feedthroughs are used 
• Given the large number of units to be supplied with DC power (2 amplifiers + 4 dividers), I chose to use two D1000217 power regulators (the default configuration takes +-18V as input, and outputs regulated +-15V, which was fine for the dividers, but the ZKL-1R5 requires +12V, so I changed the resistor R2 in the schematic from a 10.7K to 8.451K so as to accommodate this).
• The amplifiers and dividers are mounted on a steel plate, which is itself mounted on the chassis via insulating posts. 

Testing:

• I first verified the power regulator circuitry without hooking up the amplifiers/dividers - with a multimeter, I verified I was getting +15V and +12V as expected.
• I then connected the amplifiers and dividers, and decided to first check the behaviour of each channel using the Fluke 6061 RF function generator and an oscilloscope. One of the channels (X-arm in the current configuration) worked fine - I got a 0-2.5V square wave as the output for input signals as low as -38dBm at 130MHz (consistent with out earlier observations).
• The Y-arm channel however did not give me any output. In order to debug the problem, I decided to check the output after the amplifier first. The amplifier does not seem to be working for this channel - I get the same amplitude at the output as at the input. I verified that the correct DC power voltage of +12V was being supplied with a multimeter, but I am not sure how to debug this further. The amplifier is basically straight out of the box, and as far as I can tell, I have not done anything to damage it, as this was the first time I am connecting it to anything, and I repeated the same steps on the Y-arm as the X-arm, which seems to work alright.
• The rest of the Y-arm signal chain was verified to be working by bypassing the amplifier stage (the attached photographs show the box in this configuration. There seems to be no issues with the divider part of the signal chain. 

Once I figure out the problem with this amplifier/replace it, the box is ready to be installed. 

The new 2x2 fiber couplers arrived today so Eric gave me an overview on the changes to be made to the existing configuration of the FOL fiber box. I removed the box from the table after ensuring that the PDs were powered OFF and removing and capping all fiber leads on the front panel. Here is a summary of the changes made.

• On-Off positions for the rocker switches corrected - these switches for the power to the PDs were installed such that the "1" position was OFF. I flipped both the switches such that the "1" position now corresponds to ON (see Attachment #1).
• All the couplers/beam combiners/splitters were initially removed. 
• I then re-configured the layout as per the schematic (Attachment #2). I only needed to use one of the 4 new 2x2 couplers ordered. I think the 1x2 couplers are appropriate for mixing the PSL and AUX beams, as if we use a 2x2 coupler, half of the mixed light goes nowhere? Indeed, if we had one more such coupler, we could do away with the 2x2 coupler I am now using to divide the PSL light into two. 
• The spec-sheets on the inside of the top cover were updated to reflect the new hardware (Attachment #3).
• The old hardware from the box that was not used, along with their spec-sheets, are stored temporarily in a Thorlabs lab snacks box (all the fibers have been capped).
• The finished layout is shown in Attachment #4.

I then ran a quick check to see what the power levels were at the input to the PDs, using the fiber coupled power meter. However, I found that there was no light in the fiber marked "PSL light in" (the power meter read out "Sig. Low"). The X arm Aux light had an input power of 1.12 mW, which after the various coupling losses etc went down to 63 uW just before the PD. The corresponding figures for the Y arm are 200 uW and 2.2 uW. I am not too sure of how the AUX light is coupled into fibers so I am not trying to tweak the alignment to see if I get more power. 

Eric pointed out that the 1x2 couplers that were used in the previous arrangement and which I recycled, were in fact NOT appropriate - they are not 50-50 couplers but 90-10 couplers, which explains the measured power levels I quoted here.

I switched out these for a pair of the newly arrived 2x2 couplers, and have also replaced the datasheets on the inside of the top cover. I then redid the power level measurements, and got some sensible values this time (see Attachment #1 for revised layout and measured power levels, numbers in red are powers for PSL light, numbers in green are for AUX laser light, and all numbers are in mW). I did find that the 90-10 splitter in the PSL+Y path was not working (though the one in the PSL+X path seems to be working fine), and hence, have not quoted power levels at the output of these splitters. For now, I guess we can bypass the splitters and take the PSL+AUX light from the 2x2 couplers directly to the PDs.

[gautam, ericq]

We had a look at the IR beat (PSL+Xarm) today using the new FOL fiber box, and compared it to the green beat signal for the same combination. We first switched out the green Y beat input into the RF amplifiers on the PSL table with the PSL+Xarm IR beat input (so in all the plots, the BEATY channels really correspond to the IR beat for PSL+X). The IR and green beat notes were found without much difficulty, and we compared the beat signal PSDs for the green and IR signals (see Attachment #1 - arms were locked to green and the X slow control was turned on). The pink trace (labeled REF1) corresponds to the green beat signal, and was in good agreement with an earlier reference trace Eric had saved for the same signal. The teal trace (labeled REF0) corresponds to the the IR beat signal monitored simultaneously. 

We then went back to the PSL table to check the amplitude of the signal from the broadband fiber PDs using the Agilent network analyzer. An initial measurement yielded a beat note (@~50MHz) at ~-22dbm (17mV rms). We figured that by bypassing the 90-10 splitter in this path, we could get a stronger signal. But after switching out the fiber connections we found that the signal amplitude had fallen to ~-27dbm (10mV rms). As per my earlier measurements here, we expect ~600uW of light on the PD, and a quick calculation suggested the signal should be more like 60mV, so we used the fiber power meter to check the power levels after each of the couplers again. We then found that the fiber connector on the front panel of the box for the PSL input wasnt ideal (the laser power after the first 50-50 coupler was only ~250 uW, though the input was ~1.2  mW). The power after the first coupler also fluctuated unpredictably (<100 uW to 350 uW) in response to slightly tightening/loosening the fiber connections on the front panel. I then switched the PSL input to one of the two unused fiber connectors on the front panel (meant for the 10% of the beat signal for the DC readout), and found that this input behaved much better, with ~450 uW of power available after the first 50-50 coupler. The power going into the beat PD was also measured to be ~550uW, closer to what was expected. The beat signal peak now was ~-14dbm (~30mV rms).

We then once again repeated the comparison between green and IR beat signals - but while in the control room, I noticed that the beat signal amplitude on the network analyzer in the control room was fluctuating by nearly 1.5 divisions on the vertical scale - not sure what the reason for this is. A look at the PSD of the IR beat with higher power incident on the PD was also not encouraging (see blue trace in Attachment #1), it seems to have gotten worse in the 10-30 Hz range. We also looked at the coherence between the beat spectrum and the beat note amplitude in order to look for any linear coupling between the two, but from Attachment #2, we cannot explain the disparity between the green and IR beat spectra. This warrants further investigation.

Everything on the PSL table has now been restored to the configurations before these investigations (i.e. the Y+PSL green beat cable has been reconnected to the RF amplifier, and both green beat PDs have been powered back ON. The fiber PDs are powered OFF) 

The new ZKL-1R5 RF amplifier that Steve ordered arrived yesterday. I installed this in the frequency divider box and did a quick check using the Fluke RF signal generator and an oscilloscope to verify that both the X and Y paths were working. 

I've now installed the box in the 1X2 rack where the olf "RF amplifiers for ALS and FOL" box used to sit (I swapped that out as I needed the L brackets on that chassis to mount mine, see Attachment #1 for the new layout). The power cable that used to power the old chassis was available, but the connector was of the wrong gender, so I had to switch this out. After verifying that I was getting the correct voltage (+15V), I connected it to the chassis.

I then did a quick check with the Fluke generator to make sure that all was working as expected - Eric had set up some ADC channels for me earlier today in the C1ALS model, and I copied over my frequency counting module from C1TST into C1ALS, and recompiled the model. The RF generator was set to generate a 25MHz signal at -20dBm, which I then split using an RF power splitter between the X and Y arms. I then checked the output using dataviewer - I recovered an output frequency of ~27.64 MHz with a jitter of ~0.02 MHz with a 20Hz low-pass filter in place (see Attachment #2), which looks consistent with the systematic error inherent in the zero-crossing counting algorithm and random fluctuations I had observed in my earlier trials, discussed here. But a more systematic investigation needs to be carried out in this regard. The interfacing between the hardware and software seems to be working alright though. I've left the RF generator near the 1x2 rack for now, though its powered off. 

The mode cleaner unlocked quite a few times while I was working but looks stable now. 

I carried out some more tests on the digital frequency counting system today, mainly to see if the actual performance mirrors the expected systematic errors I had calculated here. 

Setup and measurement details:

I used the Fluke 6061A RF signal generator to output an RF signal at various frequencies, one at a time, between 10 and 70 MHz. I split the signal (at -15 dBm) into two parts, one for the X-channel and one for the Y-channel using a mini-circuits splitter. I then looked at the input signal using testpoints I had set up within the model, to decide what thresholds to set for the Scmitt trigger. Finally, I averaged the outputs of the X and Y channels using z avg -s 10 C1:ALS-FC_X_FREQUENCY_OUT and also looked at the standard deviation as a measure of the fluctuations in the output (these averages were taken after a low-pass filter stage with two poles at 20Hz, chosen arbitrarily).

Results:

• Attachment #1 shows a plot of the measured RF frequency as a function of the frequency set on the Fluke 6061A. The errorbars on this plot are the standard deviations mentioned above. 
• Attachment #2 shows a plot of the systematic error (mean measured value - expected value) for the two channels. It is consistent with the predictions of Attachments #3 and #4 in elog 11628 (although I need to change the plots there to a frequency-frequency comparison). This error is due to the inherent limitations of frequency counting using zero crossings, I can't think of a way to get around this).
• I found that a lower threshold of 1800 and an upper threshold of 2200 worked well over this range of frequencies (the output of the Wenzel dividers goes between 0V and 2.5V, and the "zero" level for the digitized signal corresponds to ~2000, as determined by looking at a dataviewer plot of a tetspoint I had set up in my model). Koji suggested taking a look at the raw ADC input signal sampled at 64 kHz but this is not available for c1x03, the machine that c1als runs on. 

Summary:

I carried out some further diagnostics and found some ways in which I could optimize the zero-crossing-counting algorithm, such that the error in the measured frequency is now entirely within the expected range (due to a +-1 clock cycle error in the counting). We can now determine frequencies up to ~60 MHz with less than 1 MHz systematic error and <10 kHz statistical error (fluctuations after the 20 Hz lowpass). This should be sufficient for slow control of the end-laser temperatures.

Details: 

The conclusion from my earleir tests was that there was possibly an improvement that could be made to setting the thresholds for the Schmitt trigger stage in the model. In order to investigate this, I wanted to have a look at the 64K sampled raw input to the ADCs. Yesterday Eric helped me edit the appropriate .par file for viewing these channels for c1x03, and for an input frequency of 70MHz (after division, ~4.3 kHz square wave), the signal looked as expected (top left plot, attachment #1). This prompted me to check the counting algorithm again with the help of various test points I had setup within the model. I found that there was a tendency to under-count the number of clock-cycles between zero-crossings by more than 1 clock cycle, due to the way my code was organized. I fixed this and found that the performance improved dramatically, compared to my previous trials. With the revised counting algortihm, there was at most a +-1 clock cycle error in the counting, and the systematic error between the measured and requested RF frequencies is now completely accounted for taking this consideration into account. The origin of this residual error can be understood by looking at the top right plot in Attachment #1 - presumably because of the effects of some downsampling filter, the input signal to the Schmitt trigger isnt a clean square wave (even at 4kHz) - specifically, the time spent in the LOW and HIGH states of the Schmitt trigger can vary between successive zero crossings because of the shape of the input waveform. As a result, there can be a +-1 clock cycle error in the counting process. Attachment #2 shows this - the red and blue lines envelope the measured frequency for the whole range investigated: 10-70MHz. Attachment #3 shows the systematic error as a function of the requested frequency.

If there was some way to bypass the downsampling filter, perhaps the high-frequency performance could be improved a little. 

Steve pointed out that in the aftermath of the Nitrogen running out a couple of times last week, the RGA had shut itself off thinking that there was a leak and so it was not performing the scheduled scans once a day. So the data files from the scheduled scans were empty in the /opt/rtcds/caltech/c1/scripts/RGA/logs directory. The wiki page for getting it up and running again is up-to-date, but the script RGAset.py did not exist on the c0rga machine, which the RGA is communicating with via serial port. I copied over the script RGAset.py from rossa to c0rga and ran the script on that machine - but the error flags it returned were not all 0 (indicating some error according to the manual) - so I edited the script to send just the initialize command ('IN0') and commented out the other commands, after which I got error flags which were all 0. After this, I ran a manual scan using 'RGAlogger.py', and it appears that the RGA is now able to take scans again - I'm attaching a plot of the scan results. We've saved this scan as a reference to compare against after a few days. 

I'm working on setting up a moving-average in the custom C code block that counts the zero crossings to see if this approach is able to mitigate the glitchy frequency readout due to mis-counting by one clock cycle between successive zero crossings. I'm storing an array the size of the moving average window of frequency readouts at each clock cycle, and then taking the arithmetic mean over the window. By keeping a summing variable that updates itself each clock cycle, the actual moving average process isnt very intensive in terms of computational time. The array does take up some memory, but even if I perform the moving average over 1 second with 16384 double precision numbers stored in the array, its still only 130 kB so I don't think it is a concern. Some tests I've been doing while tuning the code suggest that with a moving average over 16384 samples (i.e. 1 second), I can eliminate glitches at the 1Hz level in the frequency readout for frequencies up to 5 kHz (generated digitally using an oscillator block). Some tuning still needs to be done, and the window could possibly be shortened. I also need to take a look at the systematic errors in this revised counting scheme, preferably with an analog source, but this is overall, I think, an improvement.

On a side note, I noticed some strange behaviour while running the cds average command - even though my signal had zero fluctuations, using z avg 10 -s C1:TST-FC_FREQUENCY_OUT gave me a standard deviation of ~1 kHz. I'm not sure what the problem is here, but all the calibration data I took in earlier trials were obtained using this so it would be useful to perform the calibration again. 

I've made quite a few changes in the software as well as the hardware of the digital frequency counting setup.

• The main change on the software side is that the custom C code that counts intervals between successive zero crossings and updates the frequency output now has a moving average capability - the window size is readily changable (by a macro in the first line of the code, which resides at /opt/rtcds/userapps/release/cds/c1/src/countZeroCrossingWindowed.c - however, changing the window size requires that the model be recompiled and restarted), and is currently set to 4096 because based on some empirical trials I did, this seemed to give me the frequency output with the least jitter, and also smaller systematic errors than in my earlier trials described here.
• The filter modules for both the X and Y channels now have 2 pole butterworth low pass filters with poles at 64Hz, 32Hz, 16Hz, 8Hz, 4Hz, 2Hz and 1Hz loaded. Again, based on my empirical trials, a combination of a moving average filter in the C code and the IIR filters after that worked best in terms of reducing the jitter in the frequency readout. I think the fact that the moving average 'spreads' the impulse caused by a glitch in the counting algorithm improves the response of the combination as compared to having only the IIR filters in place. 
• The Frequency Counting SIMULINK block has been cleaned up a little - I have removed unnecessary test points I had set up for debugging, and is now a library part called "FC".
• After the experience of having C1ALS crash as noted here, I was doing all my testing in the C1TST model. Having made all the changes above, I reverted to the C1ALS model, which compiled and ran successfully this time.
• On the hardware side, I interchanged the couplers mentioned here - so the 20dB coupler now sits on the X green beat PD, while the 10dB coupler sits on the Y green beat PD. This change was motivated by wanting to test out the digital frequency counting setup by performing an arm scan through an IR resonance using ALS, and we found that the PSL+Y green beat frequency was better behaved than the X+PSL combination.

Arm scan

Eric helped me test the new setup by doing an arm scan through an IR resonance by ramping the ALS offset from -3 to +3 with a ramp time of 45 seconds. The data was acquired with the window size of the moving average set to 4096 clock cycles, and a 2 Hz low pass IIR filter before the frequency readout. Attachment 1 shows a plot of the data, and a fit with a function of the form trans = a/(1+((x-b)/c)^2), where a = normalization, b = center of lorentzian, and c = linewidth (FWHM) of the peak (the fitted parameter values, along with 95% confidence bounds are also quoted on the plot). In terms of the data acquisition, comparing this dataset to one from an earlier scan Eric did (elog11111) suggests that the frequency counting setup is working reasonably well - at any rate, I think the data is a lot cleaner than before implementing the moving average and having a 20Hz lowpass IIR filter. In any case, we plan to repeat this measurement sometime next week during a nighttime locking session. It remains to calculate the arm loss from these numbers analogous to what was done earlier for the X arm.

Calculation of loss:

Fitted linewidth = 10.884 kHz +/- 11Hz (95% C.I.)

FSR of Y arm (from elog 9804) = 3.9468 MHz +/- 1.1 kHz

=> Y arm Finesse = FSR/fitted linewidth =  362.6 +/- 0.5

Total round trip loss = 2*pi/Finesse = 0.0173

Sorry for the confusion - I did mean Green beat frequency, and I had neglected the factor of 2 in my earlier calculations. However, the fit parameter "c" in my fit was actually the half-width at half maximum and not the full width at half maximum. After correcting for both these errors (new fit is Attachment #1, where I have now accounted for the factor of 2, and the X axis is the IR beat frequency), I don't think the numbers change too much. It could be that the frequency counter wasn't reading out the frequency correctly, but looking at a time series plot of the frequency counter readout (Attachment #2), and my earlier trials, I don't think this is the case (38 MHz is a frequency at which I don't expect much systematic error - also, the offset was stepped from -3 to 3 over 45 seconds). 

The revised numbers:

Fitted linewidth = 2*c = 10.884 kHz +/- 2 Hz (95% C.I.)

FSR of Y arm (from elog 9804) = 3.9468 MHz +/- 1.1 kHz

=> Y arm Finesse = FSR/fitted linewidth =  362.6 +/- 0.5

Total round trip loss = 2*pi/Finesse = 0.0173

I found (an old) 10 dB coupler in the RF component shelves near MC2 - it has BNC connectors and not SMA connectors, but I thought it would be worth it to switch out the 20dB coupler currently on the X green beat PD on the PSL table with it. I used some BNC to SMA adaptors for this purpose. It appears that the coupler works, because I am now able to register an input signal on the X arm channel of the digital frequency counter (i.e. the coupled output from the green beat PD). I thought it may be useful to have this in place and do an IR transmissions arm scan using ALS for the X arm as well, in order to compare the results with those discussed here. However, the beat note amplitude on the analyzer in the control room looks noticeably lower - I am not sure if the coupler is responsible for this or if it has to do with the problems we have been having with the X end laser (the green transmission doesn't look glitchy on striptool though, and the transmission itself is ~0.45). In any case, we could always remove the coupler if this is hindering locking efforts tonight. 

I began my attempts to characterize the PDH loops at the X end today. My goal was to make the following measurements:

• Dark noise and shot noise of the PD
• Mixer noise
• Servo electronics noise 

which I can then put into my simulink noise-budget scheme for the proposed IR beat setup.

I've made an Optickle model of a simple FP cavity and intend to match the measured PDH error signal from the X end to the simulated error signal to get the Hz/V calibration. I'll put the plots up for these shortly.

With regards to the other measurements, I was slowed down by remote data-acquisition from the SR785 - I've only managed to collect the analyzer noise floor data, and I plan to continue these measurements during the day tomorrow. 

Over the course of my investigations into the systematic errors in the frequency readout using digital frequency counting, I noticed that my counter variable that keeps track of the number of clock cycles between successive zero crossings was NOT oscillating between 2 values as I would have expected (because of there being a +/- 1 clock cycle difference between successive zero crossings due to the fixed sampling time of 1/16384 seconds), but that there were occassional excursions to values that were +/- 3 clock cycles away. I then checked the output of the SCHMITTTRIGGER CDS library part (which I was using to provide some noise immunity), and noticed that it wasn't triggering on every zero crossing at higher frequencies. I tested this by hooking up a digital oscillator to the SCHMITTTRIGGER part, and looked at its output for different frequencies. The parameters used were as follows:

CLKGAIN: 10000

SCHMITTTRIGGER lower threshold: -1.0

SCHMITTTRIGGER upper threshold: +1.0

I am attaching plots for two frequencies, 3000Hz and 4628Hz (Attachments #1 and #2) . I would have expected a flip in the state of the output of the schmitt trigger between every pair of horizontal red lines in this plot, but at 4628 Hz, it looks like the schmitt trigger isn't catching some of the zero crossings? Come to think of it, I am not even sure why the output of the schmitt trigger takes on any values other than 0 or 1 (could this be an artefact of some sort of interpolation in the visualization of these plots? But this would not affect the conclusion about the schmitt trigger missing some of the zero crossings?)

As an interim measure, I implemented a Schmitt trigger in my C code block - it was just a couple of extra lines anyways - I have designated the schmitt trigger output as a static variable that should hold its value in successive execution cycles, unless it is updated by comparing the input value to the thresholds (code attached for reference). Attachments #3 and #4 show the output of this implementation of a Schmitt trigger at the same two frequencies, and I am seeing the expected flip in the state between successive zero crossings as expected (though I'm still not sure why it takes on values other than 0 and 1?). Anyways this warrants further investigation. An elog regarding the implications of this on the systematic error in the frequency counter readout to follow.

I was trying to take a few more IR transmission scans with ALS when the ETMX got kicked again. I'm not sure how to fix this, so for the time being, I'm leaving the Oplev servo and the LSC turned off. The oplev spot looks really far off center especially in yaw, the yaw error is ~ -80.

While the ETMx issues are being investigated - with Eric's help, I took some data from arm scans of the Y arm through ~2FSRs using ALS. I've also collected the data from the frequency counter readout during these scans but since they were done rather fast (over 60seconds), I am not sure how accurate this data will be. The idea however is to use the frequency readout from the phase tracker - this has to be linearized though, which I will do during the daytime tomorrow. The plan is to use our GPS timing unit to synchronize the following chain :

GPS timing unit 1PPS out --> FS725 Rb Clock 1PPS in (I recovered one which was borrowed from the 40m some time ago from the ATF lab yesterday evening, waiting for it to lock to the Rb clock now)

FS725 Rb Clock 10 MHz out --> Fluke 6061A 10MHz reference in

FS725 Rb Clock 10 MHz out-->agilent network analyzer 10MHz reference in (for measurement of the frequency of the signal output from the Fluke RF signal generator independent of its front panel display)

Then I plan to look at the phase tracker output as a function of the driving frequency (which will also be measured, offline, using the digital frequency counter setup) over a range of 20 MHz - 50 MHz in steps of 1 MHz. Results to follow.

Earlier tonight, Eric and I tweaked the PMC alignment (the mode cleaner was not staying locked for more than a couple of minutes, for almost an hour). 

I've made a few more changes to the frequency counting code - these are mostly details and the algorithm is essentially unchanged.

• The C-code block in the simulink model now outputs the number of clock cycles (=1/16384 seconds) rather than the frequency itself. I've kept converting this period to frequency step by taking the reciprocal as the last step of the signal chain, i.e. after the LP filter.
• In the current version of the FC library block, I've disabled the moving average in the custom C code - I've left the functionality in the code, but the window length at the moment is set to 1, which in effect means that there is no moving average. I found that comparable jitters in the output are obtained by using no moving average, and having two 2-pole IIR low-pass filters in series (at 4Hz and 2Hz) as by doing a moving average over 4096 clock cycles and then passing that through a 2Hz IIR lowpass filter (as is to be expected).

Systematic error

The other thing that came up in the meeting last week was this issue of the systematic errors in the measured frequency, and how it was always over-estimating the 'actual' frequency. I've been investigating the origin of this over the last few days, and think I've found an explanation. But first, Attachment #1 shows why there is a systematic error in the first place - because we are counting the period of the input signal in terms of clock cycles, which can only take on discrete, integer values, we expect this number to fluctuate between the two integers bounding the 'true value'. So, if I'm trying to measure an input signal of 3000Hz, I would measure its period as either 5 or 6 clock cycles, while the "true"  value should be 5.4613 clock cycles. In attachment #1, I've plotted the actual measured frequency and the measured frequency if we always undercounted/overcounted to the nearest integer clock cycles, as functions of the requested frequency. So the observed systematic error is consistent with what is to be expected.

The reason why this doesn't average out to zero is shown in Attachment #2. In order to investigate this further, I recorded some additional diagnostic variables. If I were to average the period (in terms of clock cycles - i.e. I look for the peaks in the blue cuve, add them up, and divide by the number of peaks), I find that I can recover the expected period in terms of clock cycles pretty accurately. However, the way the code is set up at the moment, the c code block outputs a value every 1/16384 seconds (red curve) - but this is only updated each time I detect a zero crossing - and as a result, if I average this, I am in effect performing some sort of weighted average that distorts the true ratio of the number of times each integer clock-cycle-period is observed. This is the origin on the systematic error, and is a function of the relative frequency each of the two integer values of the clock-cycle-period occurs, which explains why the systematic error was a function of the requested frequency as seen in Attachment #1, and not a constant offset. 

At the frequencies I investigated (10-70MHz in 5MHz steps), the maximum systematic error was ~1%.

Is there a fix?

I've been reading up a bit on the two approaches to frequency counting - direct and reciprocal. My algorithm is the latter, which is generally regarded as the more precise of the two. However, in both these approaches, there is a parameter known as the 'gate-time': this is effectively how long a frequency counter measures for before outputting a value. In the current approach, the gate time is effectively 1/16384 seconds. I would think that it is perhaps possible to eliminate the systematic error by setting the gate time to something like 0.25 seconds, and within the gate time, do an average of the total number of periods measured. Something like 0.25 seconds should be long enough that if, within the window, we do the averaging, and between windows, we hold the averaged value, the systematic error could be eliminated. I will give this a try tomorrow. This would be different from the moving average approach already explored in that within the gate-time, I would perform the average only using those datapoints where the 'running counter variable' shown in Attachment #2 is reset to zero - this way, I avoid the artificial weighting that is an artefact of spitting out a value every clock cycle. 

Summary:

I performed a preliminary calibration of the X and Y phase trackers, and found that the slopes of a linear fit of phase tracker output as a function of driven frequency (as measured with digital frequency counter) are 0.7886 +/- 0.0016 and 0.9630 +/- 0.0012 respectively (see Attachments #1 and #2). Based on this, the EPICS calibration constants have been updated. The data used for calibration has also been uploaded (Attachment #4).

Details:

I found that by adopting the approach I suggested as a fix in elog 11736, and setting a gate time of 1second, I could eliminate the systematic bias in measured frequency I had been seeing, the origin of which is also discussed in elog 11736. This was verified by using a digital oscillator to supply the input to the frequency counting block, and verifying that I could recover the driving frequency without any systematic bias. Therefore, I used this as a measure of the driving frequency independent of the front panel display of the Fluke 6061A. 

The actual calibration was done as follows:

1. Close PSL green and end green shutters. Turned off the power to the green transmission PDs on the PSL table and disconnected the couplers from their outputs.
2. Connected the output of the Fluke 6061A RF signal generator to a splitter, and to the inputs of the couplers for the X and Y signal chains.
3. Adjusted the amplitude of the RF signal output until the Q readout of the rotated X and Y outputs were between 1000 and 3000. The final value used was -17dBm. As a qualitative check, I also looked at the beat signal on the spectrum analyzer in the control room and judged the peak height to be roughly the same as that seen when a real beat note was being measured. The phase tracker gains after setting the UGF were ~83 and 40 for the X and Y arms respectively.
4. Step through the frequency from 20MHz to 70MHz in steps of 1MHz, and record the outputs of (i) Digital frequency counter readout, and (ii) Phase tracker phase readout for the X and Y arms. I used the z avg -s utility to take an average for 10 seconds, and the standard deviation thus obtained correspond to the errorbars plotted. 
5. Restore the connections to the green beat PDs and power them on again.

Y-arm transmission scan

I used the information from Attachment #2 to calibrate the X-axis of the Y-arm transmission data I collected on Wednesday evening. Looking at the beat frequency on the analyzer in the control room, between 24 and 47 MHz (green beat frequency, within the range the calibration was done over), we saw three IR resonances. I've marked these peaks, and also the 11MHz sideband resonances, in Attachment #3. It remains to fit the various peaks. I did a quick calculation of the FSR, and the number I got using these 3 peaks is 3.9703 +/- 0.0049 MHz. This value is ~23 kHz greater than that reported in elog 9804, but the error is also ~4 times greater (6 IR resonances were scanned in elog 9804) so I think these measurements are consistent.

Rubidium clock

I had brought an FS725 Rubidium clock back from W Bridge - the idea was to hook this up to the GPS 1PPS output, and use the 10MHz output from the FS725 as the reference for the fluke 6061A. However, the FS725 has not locked to the Rb frequency even though it has been left powered on for ~2days now. Do I have to do something else to get it to lock? The manual says that it should lock within 7 minutes of being powered on. Once this is locked, I can repeat the calibration with an 'absolute' frequency source...

Summary:

As an update to Yutaro's earlier post - I've done an independent study of this data, doing the fitting with MATLAB, and trying to estimate (i) the FSR, (ii) the mode matching efficienct, and (iii) the modulation depths at 11MHz and 55MHz.

The values I've obtained are as follows:

FSR = 3.9704 MHz +/- 17 kHz 

Mode matching efficiency = 92.59 % (TEM00 = 1, TEM10 = 0.0325, TEM20 = 0.0475)

Modulation depth at 11MHz = 0.179

Modulation depth at 55MHz = 0.131

Details:

• To approximately locate the TEM10 and TEM20 resonances, I followed the methodology listed here (though confining myself to (m+n) = 1,2). 
• To approximately locate the 11 MHz and 55 MHz sidebands, I used the mod command in MATLAB to locate approximately how far they should be from a carrier resonance. 
• The results of these first two steps are demonstrated pictorially in Attachment #1. Red = carrier resonance, grey = 55MHz sideband resonance, cyan = 11MHz sideband resonance, green = TEM20 resonance, and yellow = TEM10 resonance. 
• The FSR was calculated by fitting the center frequencies of fits to the three carrier resonances with a lorentzian shape, vs their index. The quoted error is the 95% C.I.s generated by MATLAB
• The mode-matching efficiency was calculated by taking the fitted height of Lorentzian shapes to the TEM00, TEM10 and TEM20 shapes. The ratio of the peak heights was taken as a measure of the fraction of total power coupled into the TEM10 and TEM20 modes relative to TEM00. In calculating the final value, I took the average of the 3 available values for each peak to calculate the ratios.
• The modulation depth was calculated by approximating that the ratio   , and solving for . Attachment #2 shows a plot of the RHS of this equation as a function of  - the two datatips mark the location of the ratios on the LHS of the equation - both P_c and P_s were averaged over the 3 and 6 values available, respectively. The values I have obtained are different from those cited here - not sure why? The real red flag I guess is that I get the modulation depth at 11MHz to be larger than at 55MHz, whereas elog10211 reports the reverse... Do we expect a resonance for a 44MHz sideband as well? If so, it could be that the two peaks close to the carrier resonance is in fact the 55.30 MHz sideband resonance, and the peaks I've identified as 55MHz sideband resonances are in fact 44MHz sidebands.. If this were true, I would recover the modulation depth for 55.30 MHz sidebands to be approximately 0.22...

Misc Remarks and Conclusions:

• The y-scale in Attachment #1 is log(transmission) - the semilogy command in MATLAB messed up the rendering of the overlaid semi-transparent rectangles, hence the need for adopting this scale...
• I've attached the code used to split the entire scan into smaller datasets centered around each peak, and the actual fitting routine, in Attachment #3. I've not done the error analysis for the mode matching efficiency and the modulation depths, I will update this entry with those numbers as soon as I do. 
• In my earlier elog11738, I had mislabelled some peaks as being sideband peaks - attachment #1 in this entry is (I think) a correct interpretation of the various peaks. 
• There are two peaks on either side of every carrier resonance, spaced, on average, about 177kHz away from the resonance on either side. I am not sure what the interpretation of this peak should be - are they the 55.30 MHz resonances? 
• These values should allow us to carry out alternative measurements of the round trip arm loss as estimating this from the cavity finesse seems to not be the best way to go about this. 

After thinking about the interpretation of the various peaks seen in the scan through 2 FSRs, I have revised the information presented in the previous elog. Yutaro pointed out that the modulation frequency isn't exactly 11MHz, but according to this elog, is 11.066209 MHz. So instead of using mod(11e6,FSR), I really should have been using mod(11.066209,FSR) and mod(5*11.066209,FSR) to locate the positions of the 11MHz and 55MHz sidebands relative to the carrier resonances. With this correction, the 'unknown' peaks identified in Attachment #1 in elog 11743 are in fact the 55MHz sideband resonances. 

However, this means that the peaks which were previously identified as 55MHz sideband resonances have to be interpreted now - I'm having trouble identifying these. If we assume that the types of peaks present in the scan are 11 MHz sideband, 55MHz sideband, and the TEM00, TEM10, TEM20, TEM30, and TEM40 mode resonances, then the peaks marked in grey in Attachment #1 to this elog can be interpreted as TEM30 (right of a carrier resonance) and TEM40 (left of a carrier resonance) mode resonances - however, the fitted center frequencies differ from the expected center frequencies (determined using the same method as elog 469) by ~3% (for TEM30) and ~20% (for TEM40) - therefore I am skeptical about these peaks, particularly the 4th HOM resonances. In any case, they are the smallest of all the peaks, and any correction due to them will be small. 

The updated modulation depths are as follows (computed using the same method as described in elog 11743, the updated plot showing the ratio of bessel functions as a function of the modulation depth is Attachment #2 in this elog):

@11.066209 MHz ---- 0.179

@5*11.066209 MHz --- 0.226

These numbers are now reasonably consistent with those reported in elog10211.

As for the mode-matching efficiency, the overall number is almost unchanged if I assume the TEM30 peaks are accurately interpreted: 92.11%. But the dominant HOM contribution comes from the first HOM resonance: (TEM00 = 1, TEM20 = 0.0325, TEM10 = 0.0475, TEM30 =  0.0056). These numbers may change slightly if the 4th HOM resonances are also correctly identified.

ETMx is still not well behaved and the mode cleaner isnt too happy either, so I think we will save the measurement of the round trip arm loss for daytime tomorrow.  

In the last few days, with Koji's help, I have recovered both the FS725 Rubidium references from W. Bridge, one from the ATF lab, and one from the CTN lab. Both are back at the 40m at the moment.

However, the one that was recovered from the ATF lab is no longer locking to the Rubidium reference frequency, although it was locked at the time we disconnected it from the ATF lab. I emailed the support staff at SRS, who seem to think that either the internal oscillator has drifted too far, or the Rb lamp is dead. Either ways, it needs to be repaired. They suggested that I run a check by issuing some serial commands to the unit to determine which of these is actually the problem, but I've been having some trouble setting up the serial link - I will try this again tomorrow. I'm also having trouble generating an RMA number that is needed to start the repair/maintenance process, but I've emailed SRS support again and hope to hear back from them soon. 

The other FS725, recovered from the CTN lab earlier today, seems to work fine and is locked to the Rb reference at the moment. I plan to redo the calibration of the phase tracker with an 'absolute' frequency reference with the help of the FS725 and out GPS timing unit tomorrow. Once that is done, the working unit can be returned to the CTN lab.