For a long time I had problems with the GPS time in frames being different from the real one.

This morning I rebooted the cymac3 and swapped the function generator with a new one.

I tested the GPS time in frames by switching on teh ESD noise at a given GPS time and checking the frames. The times are aligned.

I'll have to wait and see if this remains stable over time (in the past i saw an acculation of few seconds per day)

EDIT: I checked the two SR DS345 one against the other. Indeed, when bpth set to generate 65536 Hz, there is a continuos drift in the relative phase, accounting for one cycle over about 3.9 seconds. This would sum up to one second over ~256000 seconds, or about 3.5 days. It seems more or less comparable with the amount of GPS time mis-syncronization I saw. I'll have to wait a few days to see if the new clock is stable.

Things seems to be worse now. This morning I injected noise at GPS 1165078533 (real time, as obtained from the python command line, and consistent with what displayed in the MEDM screen) and found the injection in the data at GPS 1165078555, so 22 seconds later...

UPDATE:

Now the time difference is about 30 seconds. It seems that the real time model is about 29 seconds advanced with respect to the GPS time one gets from a python script command running on the cymac3

The GPS time I get from python is the same I get from a shell script on the workstation or on the cymac3. I checked that it is also consistent with the GPS time on cymac2.

I moved the picomotors at precise times and looked at the data in the frames. Indeed the data has the wrong time stamp.

I swapped the SR signal generator with an Agilent 33210A. Shut down and restarted the cymac3. Now the command line GPS and the IOP model GPS are aligned within one second. Let's see if it stays this way.

Update at 5pm, GPS times are still in sync.

Unfortunately, this morning the model time is again wrong...

I modified the autocenter script. Now while the picomotor is moving, the variable X3:CR1-AUTOCENTER takes the value 1, otherwise it is 0.

I put back the Stanford Reserch signal generator. On a scope, the timing signal looks good. There is a small ripple and some noise in the flat parts. I found that when I unplug the DAC timing cable, the ripple and the noise goes away. 

I'm leaving the DAC timing unplugged for the night, and I'm using a script to track the difference between the machine time and the front-end time.

For the last ~day the difference between the frontend GPS time and the machine GPS time remained constant between -1 and -2 seconds

I reconnected the DAC timing cable at

PST: 2016-12-08 09:23:06.934999 PST
UTC: 2016-12-08 17:23:06.934999 UTC
GPS: 1165253003

After that, the timing started to drift at a rate of about 1 second every 2300 seconds (4.35e-4). So the conclusion is that the culprit for the timing issue is on the DAC connection side.

My previous test showed that the timing drift was somehow related to the output of the signal generator being connected to the DAC.

Some more findings follow. When the CyMAC is powered down, the timing sent to the DAC is highly distorted. It stays the same even when I power the CyMAC up again, and it gets better only after the IOP process is started. My guess is this has something to do with the DAC board initialization. In the following: first trace is the timing signal with CyMAC off; second with the CyMAC powering on, but IOP not yet started; third when the IOP process is running.

A small residual distortion around the transitions is visible. This is not present on the original signal, or even if the ADC only is connected to the timing.

To try to debug the problem, I set up a second signal generator (not locked to the first one) and used it to provide the DAC timing. In this way ADC and DAC get their timing from two different signal generators.

I still see the same small distortion on the DAC timing. More important, I noticed that the signals generated by the DAC (here a 1kHz sinusoid) are very noisy: there is a very large glitch at every clock transition. Is this a sign that tha DAC is malfunctioning? I don't recall seeing anything like that in any other case. In both screeshots, the purple trace is the DAC output (1 kHz sinusoid) and in the second screenshot the blue trace is the DAC timing. It's clear that there is a glitch every time the clock signal transitions.

I swapped the DAC with another one, but I see the same behavior in the output signal. Here's a spectrum of the DAC output, with and without output.

I find sometimes that the probe configuration can give these distorted signals. For the Tektronix probes, its best to use a 500 MHz probe instead of the BNC clip leads. The probe also should be compensated by attaching to the gold fingers square wave generator on the scope front and adjusting the capacitor in the probe with a little screwdriver until the square wave becomes perfect.

• changed the name of the test chamber real time model from CR1 to CR0. Updated all MEDM screens and scripts (autocenter.py, auto_excite.py, crime.py)
• created new real time models CR1, CR2, CR3, CR4 to be used for the new chamber system. Created MEDM screens and updated all EPICS values
   

I added to the model CR0 an additional bias path for the ESD driver:

Some funny RGC idiosyncrasy: if you have a filter bank named "SUM", you can't add a summation block: if you do you get a name conflict at compilation time. That's why I used a matrix

Updated the MEDM screen accordingly

A quick test shows that working with a bias does not improve the ability to excite the modes. The DAC saturates at +-32k, which corresponds to +-10V out of the ADC, matched to the input range of the HV amplifier. The largest excitation of high frequency modes is obtained by using white noise, no bias, and maximum amplitude.

• Changed the library Picomotor8752.py to add a third axis 'r' that will allow moving the in-vacuum retaining ring. The controller remains connected to the workstation through a serial cable
• Tested a new NewFocus 8741 controller with USB and ethernet. The USB driver works only on Windows, so I tested it by running a Windows virtual machine. I used this trick to get the IP address of the controller. Then I wrote another library Picomotor8742.py that uses TCP/IP sockets to communicate with the driver via ethernet. Tested and working. Each driver can control up to four axis, so the user can choose which QPD centering mirror to move (1/2 or 3/4) and which axis (x or y)

I wrote an autocenter script for the four QPD in the new setup (autocenter14.py) and renamed the script for the old chamber (autocenter0.py).

Tested and working properly, with network connection to the picomotor controllers. Be aware that if the picomotor controllers are switched off, their IP address might change.

This morning Larry set up a network switch to create a local network for the power strip and the two Newport picomotor controllers. The laboratory workstation serves as gateway between the networks.

I still have to configure the power strip and the picomotor controllers to use the new static IP address.

Removed, since iit was not useful to improve the actuation authority.

I reconfigured the powerstrip and the two Newport controllers to use static IP address in the new 10.10.10.X network, using the workstation as gateway. All scripts updated and working

This morning I measured the beam profiles at the QPD positions. As expected, the beams are not gaussian there, since we are seeing the interference of the reflections from the two faces of the disks. Nevertheless, the measured sizes are

Here are the images of the beams:

The arm lever lengths (distance from the disk surface to the QPD) can be estimated from the optical drawing:

The optical gain (normalized QPD signal over disk surface angle) is given by

1. created a single interface to move the picomotors in front of QPD1 ... QPD4
   • the command qpdcenter will open an interactive python shell to control the picomotors
2. two scripts for automatic excitations are saved in /opt/rtcds/userapps/CyMAC/src/auto_excite*.py
   • they must run on the cymac. But they can be started from the control station using the commands autoexcite0 and autoexcite14
   • before starting the commands, set the parameters in the file. The two commands edit_autoexcite0 and edit_autoexcite14 will open the correct files
   • a log file of the excitation times will be saved
   • the scripts will check if there is an excitation going
3. the two commands noise0 and noise14 can be used to start awggui to inject the correct noise
4. updated the autocentering scripts, so that only one instance can run at a time.
   • launch them with the commands autocenter0 and autocenter14

We first measured the distance of the ESD from the disk in the test chamber (CR0). We had to remove the retaining ring to have reliable measurements

• distance between top of the ESD and mounting plate: 12.30 mm
• distance between top of the disk and mounting plate: 10.53 mm
• ESD thickness: 0.55 mm

So initially the distance between disk and ESD is 1.22 mm

We re-aligned the optical setup to a horizontal reference, and moved down the ESD as much as we could. It's not completely clear if the ESD is touching the disk. We'll see after pump down. The new distance from the top of the ESD to the mounting plate is about 11.80 mm, so we should have moved the ESD 0.5mm closer to the disk.

Pump down started at ~1:30pm

Excitations

• Old configuration, 1.2mm distance ESD-disk:
  • GPS before exc. 1186417492 
  • GPS after exc. 1186417546
• New configuration, 0.7mm distance ESD-disk
  • GPS before exc. 
  • GPS after exc.

The plots below compare the SNR and peak amplitude of all excited modes, in the new and old configuration. The new confgiuration is worse than the old one. This is unexpected, since the distance between ESD and disk is smaller.

However, yesterday we found out that setting the ESD so close to the disk is very tricky, and we might have some touching.

Additionally, the measured Q values of all modes are signfiicantly lower (by factors of >3), so it seems there is some additional friction. The mode frequencies are still compatible with the expected values, so it's unlikely that the ESD is touching the disk. One possible explanation for the worse Q can be residual gas damping in the area between the ESD and the disk: basically the gas moelcules that are left in the enclosed region between disk and ESD can create a viscous damping, which gets larger when the distance gets smaller [PhysRevLett.103.140601, arxiv:0907.5375]. I'll try to do some computations later today.

I realigned all optical levers to measure the 50mm disks. In brief, I moved the input 2" mirrors, the in-vacuum 2" mirrors and the PZT mirrors so that the beam hits the 50mm sample and gets back into the QPD. Re-aligned everything to the horizontal reference using water.

We set up the model x3tst to acquire at 65kHz four signals coming from the PSL lab:

• X3:TST-BEAT_OUT_DQ: beat note
• X3:TST-ACC_X_OUT_DQ: accelerometer X
• X3:TST-ACC_Y_OUT_DQ: accelerometer Y
• X3:TST-ACC_Z_OUT_DQ: accelerometer Z

I realigned the entire CR1-4 setup

• ensured that beam out of the chamber are at 6" height everywhere. Moved some iris to center them
• ensured that the beam hits the 45 degrees in-vacuum mirrors at a height of 3.78" = 96 mm
• checked that all incoming beams are roughly centered on the 45 degrees in-vacuum mirrors. Move some of them in-vacuum mirror posts
• realigned the input steering mirros horizontally and the in-vacuum mirros so that the beams reflected from a water-level are not clippe anywhere
• realigned the horizontal reference to the center of all QPDs

Nothing has happened since Steve, the visiting highschool teacher, has left. Meanwhile, some parts of the multi-color BRDF setup were delivered. I assembled everything today and realigned the lasers. Everything is ready now for a three-color BRDF measurement (the previous Richter record was 2 colors). I will claim back my video capture device as soon as possible from my neighbors and then take new images.

Elogs for the new Coatin RIng-down MEasurement lab had to start somewhere, so here is a couple of pictures of the optical table with shorter legs and of one of the two vacuum chambers that have been moved in.

We discovered a couple of days ago that the table was sitting on three legs only and the fourth one was dangling. I managed to adjust the height of the fourth leg using the large screw on the leg support. Now the table is properly supported by all four legs.

[Massimo Granata (LMA), Quentin Cassar (LMA), Gabriele] 

This week I'm visiting LMA to learn how their Gentle Nodal Suspension system works and to measure the quality factors (Q) of one of Mark Optics disks. First of all we annealed the disk for 9 hours at 900 degrees (plus 9 hours warm up and 9 hours cool down).

Then we installed the disk into the measurement system and started by searching for all the resonances.

My COMSOL simulation proved to be good enough to give us the frequencies, especiallty after a small fine tuning of the disk thickness (within specs). We identifies a total of 32 modes of different families, and measured the ring down of all of them. Since our disk has no flats, each mode is actually a doublet with very small frequency separation. The analysis software has a bandwith of 1 Hz to find the peak amplitude, so it can't resolve the two modes. When both are excited to a significant amplitude by the electrostatic actuator, we see a clear beat in the ring-down. I had to write a new fitting code to take this into account. More details will follow in a DCC document. However, here I can say that the fit works remarkably well for all modes. 

A couple of examples:

Here is a summary plot of the quality factor and loss angle for all modes. We measured Q as high as 10e6, in line with other LMA samples (2") we tested in these days. In conclusion, the Mark Optics disks, as they are, are good enough for our coating tests.

Between yesterday and today I populated one QPD board (based on D1600196), and started testing it. The transimpedance stages seems to work fine (they show about 5-6 V in ambient light). However the whitening stages show a large ~100 kHz oscillation. While trying to fix it I probably burnt one of the output drivers.

I'll continue the investigations and debugging on Monday.

Transimpendance and whitening are working properly. I can't get useful signal out of the differential stages yet. I replaced the channel 1 DRV134 that was burnt (very hot when powered on). But the new one got hot too after powring on, so there might be something else wrong there. I'm also wondering if it's ok to use an oscilloscope to look at the differential stage output. The scope will ground one of the two outputs: according to the DRV134 datasheet this should be ok, but I'll check better later on.

Today I gave up trying to fix the first board I populated, and built a second one. The good news is that it's working as expected.

With 27.5 uW incident on each quadrant, I measure about 4.5 V, which is in line with the transimpedance of 200k, a responsivity of about 0.4 A/W and ad additional gain of two coming from the differential driver.

I also measured the noise with a SR785 (it wasn't connected to a GPIB interface and I couldn't find any, so all I have are the following numbers and the attached screenshots). 

At low frequency we are dominated by 60 Hz harmonics (probably coming from the laser). At high frequency there are some large peaks of unknown origin. I can't acquire digitally the signals to compute the difference, so I don't know if the noise we see is, for example, laser intensity noise. As soon as the cymac is up and running, I'll run some more tests.

I got two new ADC and DAC boards from Rolf, with the correct PCIe interface. I installed them into the cymac and checked that the system could boot. The cymac is now sitting in the rack. As requested by Jamie I installed Debian 8.5

I turned out that all the noise I was seeing in the QPD spectrum was due to ambient light. I covered the QPD with a box and switched off all the light. As shown in the following plot the noise is lower.

Considering that in the final setup we'll have a beam spot radius of 0.5mm, the sensitivity to beam motion on the QPD will be 23e6 V/m. The following plot shows the resulting beam motion sensitivity, if limited by electroninc noise:

It's at a level of 6e-15 m/rHz at all frequencies above 120 Hz.

To mitigate the issue of ambient light pulluting the QPD signal, I mounted the prototype into a custum built box. This helps a lot. My plan is to add a short piece of black pipe in the front, to further shield from incident light.

The new box also provides a clean way to mount the QPD.

[Alena, Gabriele]

This afternoon we opened the tall belljar vacuum chamber, and took everything out of it. All the stuff that was inside the chamber is "temporarily" stored on the floor beside the optical table.

We installed a "spacer" into the chamber, made from one of the optical table legs that were sitting in the hallway. We installed one of the aluminum base plates on top of it, so that the optical components will be at the level of the viewport. Another leg and a thinner base plate are installed out of the chamber, at a similar level.

After this we closed the chamber with one of the flats used for the old chamber, and a rubber o-ring. We started the roughing pump, quickly reached a pressure below 1 mTorr and switched on the turbo pump. Unfortunately, it seems that the low pressure gauge is not working properly, so we don't know what's the pressure right now. We'll check the gauge and controller tomorrow morning and swap it out if needed.

Fixed the 307 gauge controller (a missing contact on the rair panel). The low pressure gauge was connected to 1G port and has measured 1.7E-6 torr. We are not sure since how long the turbo was operating (no vacuum logger yet).

Installed a gate valve between the roughing and tubbo pump. See below a pump down curve. The convection gauge is not calibrated. the turbo started at 14th min (at about 3 torr)

[Alena, Gabriele]

We attached one of the silicon lenses to a 1" optical post using some kapton tape, and installed it into the vacuum chamber. We built a simple periscope using standard optical component, and managed to send the optical level beam into the disk and back out.

To set a reference for the horizontal position of the disk we used the LMA method: we put a small container with water in place of the disk, and mark on a reference where the reflected beam hits out of the chamber:

We then put back the disk, and aligned it to have the beam hitting the same position. During pumdown we couldn't see any shift of the disk, judging from the position of the optical lever beam.

At 5pm the pressure was 6.5e-6 torr.

Checked again at:

• 9am, pressure was 2e-6 torr
• 11:30am, pressure was 1.5e-6 torr
• 5pm, pressure was 1.4e-6 torr

This afternoon I completed the assembly of the electronics boards to interface the ADC and DAC. The ADC is interfaced with a new custom board, which accepts up to eight QPD inputs, the syncronization signal, and it's connected to the ADC:

For the DAC I used one spare board from the Crackle experiment. However, that board had a wrong pinout for the DAC side connector, so I had to implemented again the same hack I did for the crackling noise experiment. 

All boards are connected to the ADC and DACs, and to the syncronization signal generated with a SR DS345. No boxes for the moment being, I'll figure out a better organization of the boards in the future if needed. I still haven't tested if the real time system is able to communicate properly with the new interfaces.

Please see prosidures for pumping down and venting with air for the test vacuum chamber here https://dcc.ligo.org/T1600304

Using the already installed high voltage feedthrough, I cabled one of the electrostatic actuators (1mm gap between electrodes) and installed it into the chamber. One of the electrodes is connected to the feedthrough cenral pin, the other is grounded on the bottom of the chamber.

The electrostatic actuator is mounted at about 1 mm above the disk, see pictures.

As a preliminary test, I checked that switching the HV amplifier on and off with about 1.5kV produces a visible motion (~2-3 mm) of the optical lever beam. So the actuator is working.

I connected the QPD to the ADC interface with a temporary cable running on the floor.

I could get signals. I still have a problem with the digital system: I can't access test points with dataviewer, but I get them with DTT. This will have to be fixed.

Following Alena's procedure, at about 1:30pm LT I started the chamber pump down. At 14:15pm LT the pressure was still 240 mTorr

At 6:20pm the pressure was about 70 mTorr, so I started the turbo pump.

Today at 1:40pm pressure is 8.5e-7 Torr