Tried the script 3 times and it didn't come back. Pkill'd and then scripted. That worked.

I modified elogd.c as shown below in order not to allow to display all of the entries at once by specifying page number "0".

After this modification, elog seems to have survived 66 times of attacks by googlebots.

==============================

rossa:src>pwd
/cvs/cds/caltech/elog/elog-2.8.0/src

rossa:src>diff elogd.c_orig elogd.c
19912a19913,19917
>
>    /* KA */
>    if (page_n<1)
>      page_n = 1;
>


On the plus side, it was the first time I've had to do it in a while..

The elog was not responding. I attempted to restart it by running .../start-elog.csh, but this didn't work (even after the usual ~2 times it needs).

Somehow pkill did not kill the daemon, so I kill -9'd it and that did the trick. I ran the start script once more and it came back online.

 Aim: to scan the cavitymodes of IMC

The circuit used: 

 Attachment4

Results obtained:

Attachment 1,2,3

I deleted a bunch of useless categories from the 40m elogd.cfg file. IF you find your category has been deleted, you can now learn how to categorize yourself into the existing categories. ELOG restarted and log file zeroed.

 The ELOG was frozen, with this in the .log file:   

GET /40m/?id=1279&select=1&rsort=Type HTTP/1.1

Cache-Control: no-cache

Connection: Keep-Alive

Pragma: no-cache

Accept: */*

Accept-Encoding: gzip, deflate

From: bingbot(at)microsoft.com

Host: nodus.ligo.caltech.edu

User-Agent: Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)

  (hopefully there's a way to hide from the Bing Bot like we did from the Google bot)

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

 Plans for the Week:

• Phase and noise characterization of the UFC RF Frequency Counter.
•  Characterization of the temperature actuator.

Progress and Problems Faced:

• Since past two days, I have been trying to measure the phase difference between the input and output signals of the FC using a 16 bit ADC ADS1115 (for input phase measurement) on Raspberry Pi(RPI).For that I have assembled a Circuit on a breadboard( Details will be mentioned in my next eLog). 
• The interfacing and the codes seem to be alright but the RPI is not able to detect the address of the ADC chip. I will try to debug the issue as soon as possible and try to take data through the Pi so that I can have both delay and noise introduced by the FC.
• Now since the minimum sampling time of the FC has been brought down to 0.1s, I will test how accurately the FC is writing values every 0.1 s for a modulating input.
• The output data of the FC will be fitted into the input and the order of accuracy will be presented.Also the gain plots will be plotted at higher frequencies like 50 MHz, 100 MHz, 500 MHz and 1000 MHz using the network analyzer.

Work Inside the Lab:

• On Friday Morning I will  go inside the  lab with Manasa to make measurements from the NPRO to characterize its response to the temperature.
• I will be in the lab in the morning session(9 am- 1 pm) and make the required measurements. I will then analyze the data and by the end of the week will finish characterization of the FC and temperature actuator.
• For the rest of the time in this week, I'll be on my desk and will not be entering  the lab.

Electronics Required:

• I will require the network analyzer on Wednesday and Thursday to make measurements at higher frequencies(30 MHz <F<1000 MHz) from the R PI.

Goal- By the end of the week:

• To characterize both the FC and the NPRO that would go into the FOL-PID loop.
• The FC will be ready to replace the network analyzers that are currently being used in the 40m.

 I was asked to calculate the lenses that we need in order to obtained a Gouy phase close to 90 degrees between the two mirrors that are in the Xend green. Yesterday, I measured the distances between the mirrors, and the distance between the mirror relative to the cavity as illustrate in the image attached below. I looked in to the 40m elog and Manasa did the last update on the length of the cavity. She measured 37.7 + 0.05m. The waist size of the beam that was measured by Annalisa in ID 8637 after the Faraday was w0=2.943e-5m @ -0.039m. I calculated the waist size inside the cavity, and I found a waist of w0=2.2 mm. My plan this week is to keep working in the calculation and finish all the calculation this week so that next week I can go inside and place the lenses. 

Yesterday elog was excruciatingly slow, and bingbot was the culprit. It was slurping down elog entries and attachments so fast that it brought nodus to its knees. So I created a robots.txt file disallowing all bots, and placed it in the elog's scripts directory (which gets served at the top level). Today the log feels a little snappier -- there's now much less bot traffic to compete with when using it.

We might be able to let selected bots back in with a crawl rate limit, if anyone misses searching the elog on bing.

Oh, this is cool! Thanks!
I could not figure out how to place robot.txt as it was not so obvious how elogd handles the files in the "logfile" directory.

I tried to find my own entry and faced with a strange behavior of the elog.

The search button invoked the following link and no real search has been done:

http://nodus.ligo.caltech.edu:8080/40m/?mode=summvry&reverse=0&reverse=1&npp=50&m&y&Authorthor=Koji

Summvry? Authorthor?

If I ran the following link, it returned correct search. So something must be wrong.

http://nodus.ligo.caltech.edu:8080/40m/?mode=summary&npp=50&Author=Koji

In order to fix ELOG search, I have started running ELOG v2.9.2 on Nodus.

Sadly, due to changes in the software, we can no longer use one global write password. Instead, we must now operate with registered users.

Based on recent elog users, I'll be creating user accounts with the following names, using the same old ELOG write password. (These will be valid across all logbooks)

• ericq
• rana
• koji
• diego
• jenne
• manasa
• Steve
• Kate
• Zach
• Evan
• Aidan
• Chris
• Dmass
• nicolas
• Gabriele
• xiaoyue

All of these users will be "Admins" as well, meaning they can add new users and change settings, using the "Config" link.

Let me know if I neglected to add someone, and sorry for the inconvenience.

RXA: What Eric means to say, is that "upgrading" from Solaris to Linux broke the search and made us get a new elog software that;s worse than what we had.

 So, despite having registered users, it turns out that the "Author" field is still open for editing when making posts. I.e. we don't really need to make new accounts for everyone. 

Thus, I've made a user named "elog" with the old write password that can write to all ELOGs. 

(Also, I've added a user called "jamie")

No elog response from outside and no elogd process on nodus, so I restarted it using 'start-elog.csh'.

If it all possible, don't use links to your home directory. Its not robust. It would be like if you clicked on your Google Music and it told you to ask me to sing that song to you. Imagine that on auto-repeat next time your fancy-bone itches.

Elogd have been restarted several times today because it died everytime I submit something.
Here is the copy of the log.

"Why does the word wrapping not work in our browsers with ELOG?" I sometimes wonder. Some of the elogs are fine, but often the 40m one has the text run off the page.

I found that this is due to people uploading HUGE images. If you need to do this, just use the shrink feature in the elog compose window so that we only have to see the thumbnail at first. Otherwise your 12 MP images will make it hard to read everyone else's entries.

(keerthana, gautam, jon)

In the morning, Jon gave me an overview of the Auxiliary laser system which we are planning to setup. Based on the diagram he uploaded in the elog, I have made the MEDM diagram for controlling and displaying the parameters. Here the parameters which we will be controlling are temperature (in terms of voltage), oscilator frequency ( with the help of IFR 2023B), the frequency offset and the PID controls. The display includes the beat frequency, error signal voltage, control voltage and a switch to give feed back to the AUX laser. As the frequency counter is not connected at the moment, I haven't included its channel number in it. The screenshot of the diagram is attached with this. I am also considering to give a PID feedback to the slow control from the AUX feedback signal. The screen can be accessed from the PSL dropdown menu in sitemap.

I think this table will help us to fix the scanning range of the Marconi frequency. This will also help in predicting the position of the resonance peak corresponding to the injected frequency.

f_diff = f_m ±80 MHz ;                     f_diff = N*FSR_y ;              FSR_y = 3.893 MHz.

The values obtained from both analytical and finesse solution is given in the above table along with the corresponding percentage errors.finesse1.pdf

The parameters used for this calculation are listed below.

Parameter	Value
length of the cavity (L)	38.5 m
Wavelength of the laser beam ()	1064 nm
Radius of curvature of ITM (R1)
Radius of curvature of ETM (R2)	58 m

The cavity scan data obtained from Finesse is also attached here.

Hmm? What is the definition of the percentage error? I don't obtain these numbers from the given values.
And how was the finesse value obtained from the simulation result? Then what is the frequency resolution used in Finesse simulation?

The percentage error which I found out =[(analytical value - finesse value)/analytical value]*100

But inorder to find the finesse value, I just used curser to get the central frequency of each peak and by substracting one from the other I found TMS and FSR.

The resolution was 6500 Hz. Thus, it seems that this method is not actually reliable. I am trying to find the central frequency of each mode with the help of lorentzian fits. I am attaching a fit which I did today. I have plotted its residual graph also.

I am uploading 4 python scripts to the github.

1. Analytical Solution

2. Finesse model- cavity scan

3. Finesse model- fitting

4. Finesse model- residual

fitting_1.pdf

> The percentage error which I found out =[(analytical value - finesse value)/analytical value]*100

Yes, I this does not give us 0.70%

(3.893408 - 3.8863685)/3.893408 *100 = 0.18%

But any way, go for the fitting.

Oopss !! I made a mistake while taking the values from my notes. Sorry.

I have modified the code for frequency scanning and have made it completely command line enabled. The code is written in python. It is saved in the name "frequency_scanning_argparse.py". I have uploaded it to the Mode-Spectroscopy Github repository.

Inorder to use this code there are two ways.

1. We can mention the ' frequency' on which marconi need to work. Then it will change the marconi frequency to that perticular value.

eg: Type in the terminal as follows for changing the marconi frequency to 59 Mhz.

python frequency_scanning_argparse.py 59e6

2. Inorder to give a scan to the marconi frequency, provide the 'start frequency', 'end frequency' and the 'number of points' in between. This will be more conveniant when we want to run the scan in different ranges.

eg: Type in the terminal as follows for a start frequency of 59 Mhz, end frequency of 62MHz and number of points in between equal to 1000.

python frequency_scanning_argparse.py 59e6 62e6 1000

In both cases the code will show you the frequency of the marconi before we run this code and it will change the marconi frequency to the desired frequency.

(Jon, Keerthana, Sandrine)

We tried to align the AUX and PSL laser yesterday. We collected the data from the spectrum analyser for the Y-ARM reflection and also for the Y-ARM transmission from the ETM mirror. I am attaching the plots here.

• N/S ARM FL.
• N/S ARM INC.

These two lights inside the 40m-lab are not working.

(Analisa, Sandrine, Keerthana)

Today Annalisa helped us to understand the new set up used to make the frequency scans of the AUX laser. While tracking the cables it seemed that there were quite a lot of cables near the mixer. So we have reconnected one of the splitter which was splitting the RF out put signal from the Agilent and have placed it just near the Agilent itself. A picture of the changed setup is provided below. The splitter divides the signal into two components. One goes to the LO port of the mixer and the other goes to the R port of the Agilent. We have tried locking the PLL after the change and it works fine. We are trying to make a diagram of the setup now, which we will upload shortly.

I tried to compare the cavity scan data we get from the Finesse simulation and that we expect from the Analytical solution. The diagram of the cavity I defined in Finesse is given below along with the values of different quantities I used. For the analytical solution I have used two different equations and they are listed below.

Analytical 1 - Blue Graph

Analytical 2 - Red Graph

The graph obtained from both these solutions completely matches with each other.

Finesse Solution

The cavity which I defined in Finesse is shown below. The solution from Finesse and the Analytical solution also matches with each other. Another plot is made by taking the difference between Finesse solution and Analytical solution. The difference seems to be of the order of .

The Difference plot is also attached below.

All of our wikis (except the 40m one which unfortunately got turned into ligo.org mess) use DokuWiki. This now has an auto-upgrade feature through the Admin web interface.

I tried this recently and it fails with this message:

DokuWiki 2018-04-22a "Greebo" is available for download.
 You're currently running DokuWiki Release 2017-02-19e "Frusterick Manners".
 New DokuWiki releases need at least PHP 5.6, but you're running 5.4.16. You should upgrade your PHP version before upgrading!

So we'll have to wait until SL7 (which is what NODUS is running).

I DID do a 'yum upgrade' which updated all the packages. I also installed yum-cron so that the RPM listings get updated daily. But sadly, SL7 only has PHP 5.4.16 (which is a June 2013 release):

> Package php-5.4.16-43.el7_4.1.x86_64 already installed and latest version

Updated the cert in /etc/httpd/ssl. The new cert is good until March 12, 2022.

found it unresponsive. Restarted fine using procedure documented in wiki

 The bridge support posts were shimmed today. Surgical tubing 402R - o - rings were glued togeather with " instant krazy glue "

Atm2  Carey CH-3540 latches are compressed ~2.5 mm in the clamped position.

Atm3 is showing the captured quick release pin in the steel reinforced bridge that is supported by the post. It works great. The post screw is sealed by o-ring. The quick-pin is sealed by an epoxy attached copper cap.

Atm4 Enclosure is on it's back. Bottom o-ring can be seen. The hole reinforced bridge structure is visible.

Now I'm working on the window connection to the chamber. I'm very close leak checking this box.

In case of leaking around the top tubing seals we have two options:

a, cut down on the cover rim by 0.040"  or b, increase tubing diameter

 Temporary oplev in place. The spot on the qpd is still big. My two lens solution did not work.

I will finalize optical component position of the oplev after the the arm transmitted and green beam optics in place. They have priority.

 Oplev spot size on qpd ~ 1 mm 

PS: I realized it later that the returning beam is going through a lens for TRY. This is a nono.

      This beam path will be relayed again as the TRY, green beam and IP-ang get there place.

 Oplev is disabled. I removed one of the steering mirrors because it was on the green beam  path.

 Since the beam waist after the Faraday had changed since the last time I measured it (maybe alignment changed a bit), I made a new mode matching calculation for green. I attached the results.

I'm going to align the beam into the Yarm.

RXA: JPG images deleted - replace with PDF please.

The PI pzt holders are back from the shop. They are numbered 1, 2 & 3 and machined to match.

Tapered black delrin opener is to gauge the gap if it is too small to fit pzt. This is to prevent holder to be opened too much.

 Thin wall connector from McMCarr#55275K25 was tested in 150 mW, 1 mm beam size of 1064 nm  overnight. It did not show any degradation.

  This entry is meant to be a sort of inventory check and a tentative plan-of-action for the installation of the PZT mounted mirrors and associated electronics on the Y-endtable. 

Hardware details:

•  PZT mounts are cleaned and ready to be put on the end-tables.
• The PZTs being used are PI S-330.20L Piezo Tip/Tilt Platforms. Each endtable requires two of these. The input channels have male single-lemo connectors. There are 3 channels on each tip/tilt platform, for tilt, yaw and a bias voltage.
• The driver boards being used are D980323 Rev C. Each board is capable of driving 2 piezo tip/tilt platforms. I am not too sure of this but I think that the SMA female connector on these boards is meant to be connected with the bias voltage from our Kepco high-voltage power supplies. The outputs on these boards are fitted with SMB female connectors, while the piezo tip/tilt platforms have male single-lemo connectors. We will have to source cables with the appropriate connectors to run between the end-table and rack 1Y4 (see below). The input to these boards from the DAC will have to be made with a custom ribbon connector as per the pin out configuration given in the circuit drawing.
• High-voltage power supply: KEPCO BHK 300-130 MG. This will supply the required 100V DC bias voltage to the piezo tip/tilts via the driver board. Since each board is capable of driving two piezos, we will only need one unit per end-table. The question is where to put these (photo attached). It doesn't look like it can be accommodated in 1Y4 (again photo attached) and the power cable the unit came with is only about 8ft long. If we put these under the end-tables, then we will need an additional long (~10m) cable to run from these to the driver boards at 1Y4 carrying 100 V. 
  
•  We will need long (~10m by my rough measurement at the X and Y ends) cables to run from rack 1Y4 to the endtable to drive the piezos. These will have to be high-voltage tolerant (at least to 100V DC) and should have SMB male connectors at one end and female single-lemo connectors at the other. I have emailed 3 firms (CD International Technologies Inc., Stonewall Cables, and Fairview Microwave) detailing our requirements and asking for a quote and estimated time for delivery. We will need 6 of these, plus another cable with an SMA connector on one end and the other end open to connect the 100V DC bias voltage from the high voltage power supply to the driver boards (the power supply comes with a custom jack to which we can solder open leads). We will also possibly need ~3m long lemo-to-?(I need to check what the input connector for the data acquisition channels) cables for the monitoring channels, I am not sure if these are available, I will check with Steve tomorrow.

Other details:

• I have attached a wiring diagram with the interconnects between various devices at various places and the type of connectors required etc. The error signal will the the transmitted green light from the cavity, and there is already a DQ channel logging this information, so nothing additional wiring is required to this end.
• Jamie had detailed channel availability in elog 8580. I had a look at rack 1Y4, and there were free DAC channels available, but I am not sure as to which of the ones listed in the elog it corresponds to. In any case, Jamie did mention that there are sufficient channels available at the end-stations for this purposes, but all of these are fast channels. What needs to be decided is if we are going ahead and using the fast channels, or if we need to find slow DAC channels. 
• I spoke to Koji about gluing the mirrors to the PZTs, and he says we can use superglue, and also to be sure to clean both the mirror and the tip/tilt surfaces before gluing. In any case, all the other hardware issues need to be sorted out first before thinking about gluing the mirrors.

High-Voltage Power Supply

Situation at rack 1Y4

 Wiring diagram

 This is an update on the situation as far as PZT installation is concerned. I measured the required cable (PZT driver board to PZT) lengths for the X and Y ends as well as the PSL table once again, with the help of a 3m long BNC cable, just to make sure we had the lengths right. The quoted cable lengths include a meter tolerance. The PZTs themselves have cable lengths of 1.5m, though I have assumed that this will be used on the tables themselves. The inventory status is as follows.

1. Stuff ordered:
   • RG316 LEMO 00 (female) to SMB (female) cables, 10 meters - 6pcs (for the Y-end)
   • RG316 LEMO 00 (female) to SMB (female) cables, 11 meters - 6pcs (for the X-end)
   • RG316 LEMO 00 (female) to SMB (female) cables, 15 meters - 8pcs (6 for the PSL, and two spares)
   • RG316 SMA (male) to open cables, 3 meters - 3pcs (1 each for the X end, Y end and PSL table, for connecting the driver boards to the 100V DC power supply)
   • 10 pin IDC connectors for connecting the DAC interface to the PZT driver boards 
2. Stuff we have:
   • 40 pin IDC connectors which connect to the DAC interface
   • PZT driver boards
   • PZT mounts
   • Twisted ribbon wire, which will be used to make the custom ribbon to connect the 10 pin IDC to the 40 pin IDC connector

I also did a preliminary check on the driver boards, mainly to check for continuity. Some minor modifications have been made to this board from the schematic shown here (using jumper wires soldered on the top-side of the PCB). I will have to do a more comprehensive check to make sure the board as such is functioning as we expect it to. The plan for this is to first check the board without the high-voltage power supply (using an expansion card to hook it up to a eurocrate). Once it has been verified that the board is getting powered, I will connect the high-voltage supply and a test PZT to the board to do both a check of the board as well as a preliminary calibration of the PZTs.

To this end, I need something to track the spot position as I apply varying voltage to the PZT. QPDs are an option, the alternative being some PSDs I found. The problem with the latter is that the interfaces to the PSD (there are 3) all seem to be damaged (according to the labels on two of them). I tried connecting a PSD to the third interface (OT301 Precision Position Sensing Amplifier), and hooked it up to an oscilloscope. I then shone a laser pointer on the psd, and moved it around a little to see if the signals on the oscilloscope made sense. They didn't on this first try, though this may be because the sensing amplifier is not calibrated. I will try this again. If I can get one of the PSDs to work, mount it on a test optical table and calibrate it. The plan is then to use this PSD to track the position of the reflected beam off a mirror mounted on a PZT (temporarily, using double sided tape) that is driven by feeding small-amplitude signals to the driver board via a function generator. 

Misc

The LEMO connector on the PZTs have the part number LEMO.FFS.00, while the male SMB connectors on the board have the part number PE4177 (Pasternack)

Plan of Action:

• The first task will be to verify that the board is working by the methods outlined above.
• Once the board has been verified, the next task will be to calibrate a PZT using it. I have to first identify a suitable way of tracking the beam position (QPD or PSD?)
• I have identified a position in the eurocrate at 1Y4 to install the board, and I have made sure that for this slot, the rear of the eurocrate is not hooked up to the cross-connects. I now need to figure out the exact pin configuration at the DAC interface: the bank is marked 'DAC Channels 9-16' (image attached) but there are 40 pins in the connector, so I need to map these pins to DAC channels, so that when making the custom ribbon, I get the pin-to-pin map right.

The wiring scheme has been modified a little, I am uploading an updated one here. In the earlier version, I had mistaken the monitor channels as points from which to log data, while they are really just for debugging. I have also revised the coaxial cable type used (RG316 as opposed to RG174) and the SMB connector (female rather than male).

With the help of an expansion card,  I verified that the + 15V and + 24V from the eurocrate in the slot I've identified for the PZT driver boards are making their way to the board. The slot is at the right-most end of the eurocrate in 1Y4, and the rack door was getting in the way of directly measuring these voltages once I hooked up the driver board to the expansion card. So I just made sure that all the LEDs on the expansion card lit up (indicating that the eurocrate is supplying + 5, + 15 and + 24V), and then used a multimeter to check continuity between the expansion card and the driver board outside of the eurocrate. The circuit only uses + 15V and + 24V, and I checked for continuity at all the IC pins marked with these voltages on the schematic.

Since the whole point of this test was to see if the slot I identified was delivering the right voltages, I think this is sufficient. I will now need to fashion a cable that I can use to connect a DC power supply to the PZT driver boards so that these can be tested further.

The high voltage points (100V DC) remain to be tested.

 I did the following with the PZT Driver Board: 

•  With an expansion card attached to the driver board, I used an Agilent E3620A power supply to verify that the 15V and 24V supplies were reaching the intended ICs. It turns out that the +24 V supply was only meant to power some sort of on-board high voltage supply which provided the 100V bias for the PZTs and the MJE15030s. This device does not exist on the board I am using, jumper wires have been hooked up to an SMA connector on the front panel that directly provides 100V from the KEPCO high voltage supply to the appropriate points on the circuit.

•  All the AD797s as well as the LT1125CS ICs on the board were receiving the required +15V.

    

The next step was to check the board with the high-voltage power supply connected.

•  The output from the power supply is drawn from the rear output terminal strip of the power supply via pins TB1-2 (-OUT) and TB1-7 (+OUT). I used a length of RG58 coaxial cable from the lab and crimped a BNC connector on one end, and stripped the other to attach it to the above pins.

•  There are several options that can be configured for the power supply. I have left it at the factory default: Local sensing (i.e. operating the power supply using the keypad on the front of it as opposed to remotely), grounding network connected (the outputs of the power supply are floating), slow mode, output isolated from ground.
  

• I was unsure of whether the grounding network configuration or the 'positive output, negative terminal grounded' configuration was more appropriate. Koji confirmed that the former was to be used so as to avoid ground loops. When installed eventually, the eurocrate will provide the ground for the entire system.
• I then verified the output of the HV power supply using a multimeter from 2V up to 150V.
• I then connected the high voltage supply to the PZT driver board with a BNC-SMA adaptor, set, for a start, to output 30V. Ensured that the appropriate points on the circuit were supplied with 30V.
  

I then hooked up a function generator in order to simulate a control signal from the DAC. The signal was applied to pin 2 of the jumpers marked JP1 through JP4 on the schematic, one at a time. The signal applied was a 0.2 Vpp, 0.1 Hz sine wave.

•  The output voltage was monitored both using a DMM at the SMB output terminals, and at the monitor channels using an oscilloscope. The outputs at both these points were as expected.
• There are 4 potentiometers on the board, which need to be tuned such that the control output to the piezos are 50V when the input signal is zero (as this corresponds to no tilt). The gain of the amplifier stage (highlighted in the attached figure) right now is ~15, and I was using 30V in place of 100V, so an input signal of 2V would result in the output saturating. This part of the circuit will have to be tuned once again after applying the full 100V bias voltage. 
• Koji suggested decreasing the gain of the amplifier stage by switching out resistor R43 (and corresponding resistor in the other 3 stages on the board) after checking the output range of the DAC so that possibility of unwanted saturation is minimised. I need to check this and will change the resistors after confirming the DAC output range. 
• The potentiometers will have to be tuned after the gain has been adjusted, and with 100V from the high-voltage DC power supply. 

To Do:

• Switch out resistors
• Tune potentiometers with 100V from the HV supply
• Verify that the output from the board after all the tuning lies in the range 0-100V for all possible input voltages from the DAC.
• Once the output voltage range has been verified, the next step would be to connect a PZT to the board output, affix a mirror to the tip/tilt, and perform some sort of calibration for the PZT. 

ETMY optical table top was grounded to the ETMY chamber through 1 Mohms this morning. I  also strain releifed relieved a few cables that were pulling on components directly.

 Summary:

I measured the maximum output of the DAC at 1Y4 as well as its power spectrum. The results are as follows (plots below):

• Maximum amplitude of differential output: + 10V.
• Power spectrum has a peak at 64 kHz.

Therefore, the gain of the high-voltage amplification stage on the PZT driver boards do not need to be changed again, as the required output range of 0-100V from the DAC board was realised when the input voltage ranged from -10V to +10 V w.r.t ground. The AI board converts the differential input to a single ended output as required by the driver board.

I will now change some resistors/capacitors on the AI board such that the position of the notches can be moved from 16k and 32k to 64k and 128k.

Procedure:

 Max. amplitude measurement

My previous measurement of the maximum output amplitude of the DAC was flawed as I made the measurement using a single channel of the oscilloscope, which meant that the negative pin of the DAC channel under test was driven to ground. I redid the measurement to avoid this problem. The set up this time was as follows:

• Positive pin of DAC connected to channel 1 of oscilloscope using break out cable and mini-grabber probe
• Negative pin of DAC connected to channel 2 of oscilloscope
• Grounds of channels 1 and 2 connected (I just hooked the mini-grabbers together)
• Measurement mode on oscilloscope set to channel 1 - channel2
• Used excitation points set up earlier to output a 3 Hz sine wave with amplitude of 32000 counts from channel 9 of the DAC. 

The trace on the oscilloscope is shown below;

So with reference to ground, the DAC is capable of supplying voltages in the range [-10V 10V]. This next image shows all three traces: positive and negative pins of DAC w.r.t ground, and the difference between the two.

 Power spectrum measurement

I used the SR785 to make the measurement. The set up was as follows:

• Positive pin of DAC to A-input of SR560
• Negative pin of DAC to B-input of SR560
• A-B output to Channel 1 input A of the SR785
• SR785 configured to power spectrum measurement

Initially, I output no signal to the DAC, and obtained the following power spectrum. The peak at 65.554 kHz is marked.

I then re-did the measurement with a 200 Hz (left) and 2000 Hz(right), 1000 counts amplitude (I had to change the Ch1 input range on the SR785 from -18dBm to -6dBm) sine wave from channel 9 of the DAC, and obtained the following. The peaks at ~64 kHz are marked.

Now that this peak has been verified, I will work on switching out the appropriate resistors/capacitors on the AI board to move the notches from 16k and 32k to 64k and 128k. 

We need the unit of the voltage power spectrum density to be V/sqrt(Hz).
Otherwise we don't understand anything / any number from the plot.