40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 Coating Ring-down Measurement Lab elog, Page 1 of 18 Not logged in
ID Date Author Type Category Subject
3   Fri Jul 13 20:53:35 2012 janoschOpticsCharacterizationtwo images

The following two pictures were taken from the same angle with green (left) and red (right) incident laser at an angle of 15deg from the incident beam (reflected to about -5deg). Some scattering centers are collocated. The green laser power is about 5 times as high as the red laser power, but this factor does not seem to calibrate the image well (the green image becomes too dark dividing all pixel values by 5). So there seems to be a significant difference in the divergence of the two lasers. We will have to use a photodiode to get the calibration factor. These images were taken after cleaning the mirror. Before cleaning, there was way too much scattering and the images were mostly saturated.

41   Thu Jul 14 16:56:00 2016 AlenaFacilityDaily Progresstest vacuum system

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

7   Tue Jul 24 10:59:59 2012 janoschOpticsCharacterizationsum of purple and red

We played around with Matlab today. The first step was to convert light wavelengths into RGB colors. In this way we can combine images taken at different colors. The picture shows the purple and red images (stored in gray scale) in heat colormap. Then the sum of these two images is calculated in their natural RGB colors.

1   Wed Jul 11 23:01:01 2012 janoschOpticsCharacterizationstarting the multi-color scatter experiment

Steve Maloney, a visiting highschool teacher, and I have started to set up a new scattering experiment in the Richter lab. The idea is to take images of large-angle scattered light using different lasers. We have one 633nm laser, and 532nm and 405nm laser pointers. The goal is to uniformly illuminate the same disk of about 1cm diameter on a silver-coated mirror with all three colors. We use a silver-coated mirror to make sure that the light is reflected from the same layer so that all colors are scattered from the same abberations.

The image shows one of the laser pointers and the HeNe laser. The first step is to widen the beam with a f=5cm broadband, AR coated lens (Newport PAC15AR.15). The diverging beam is then aligned through an iris to give it the right size on the mirror. In this way, illumination is almost uniform on the mirror surface.

The mirror is mounted over the rotation axis of a unipolar stepper motor. For the moment we only took images from fixed direction (initially with a commercial digital camera, later with a monochromatic Sony XT-ST50 CCD camera. The problem with the commercial camera was that you cannot completely control what the camera is doing. Also it would have been very difficult to calibrate the image once you start comparing scattering with different colors. A f=7.5cm lens is used to image the illuminated disk on the CCD chip to make maximal use of its resolution. The CCD signal is read out on a Windows machine with an EasyCap video capture device connected to a USB port. Standard software can then be used to take images or record videos. For some reason the capture device reduces the image size to 640x480 pixels (a little less than the size of the CCD chip).

Eventually the camera and lens will be mounted on a metal arm whose orientation is controlled by the stepper motor. The stepper motor was part of the Silicon Motor Reference Design (Silicon Laboratories). It comes with all kinds of cables and a motor control board. Software is provided to upload compiled C code to the board, but for our purposes it is easiest to use primitive communication methods between the PC and the board. We are working with HyperTerminal that used to be part of Windows installations, but now it has to be downloaded from the web. This program can send simple commands through TCP/IP and COM ports. These commands allow us to position the motor and define its rotation speed. Since our PC does not have a serial port, we purchased a Belkin USB Serial Adapter. You will have to search the web to find suitable drivers for Windows 7 x64. Luckily, Magic Control Technology has similar products and the driver for their U232-P9 USB/serial adapter also works for the Belkin product.

So our goal for the remaining weeks is to take many images from various angles and to set up the experiment in a way that we can VNC into our lab PC and control everything from the Red Door Cafe.

131   Wed Sep 28 10:26:58 2016 ranaGeneralGeneralreferences on ideal glasses

### Some easy to read reviews on thin films and ideal glass for people getting started in this Q measuring game.

1. M. D. Ediger, in PNAS  (2014), pp. 11232–11233.

2. A. J. Leggett and D. C. Vural, arXiv cond-mat.dis-nn, arXiv:1310.3387 (2013).

3. L. Berthier and M. D. Ediger, arXiv cond-mat.mtrl-sci, 40 (2015). Phys. Today.

4. G. Parisi and F. Sciortino, Nature Materials 12, 94 (2013).

5. S. Singh, M. D. Ediger, and J. J. de Pablo, Nature Materials 12, 139 (2013).

8   Fri Oct 12 16:23:20 2012 janoschOpticsDaily Progressreassembled setup

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.

6   Fri Jul 20 18:35:42 2012 janoschOpticsCharacterizationpurple improvements and first uncalibrated BSDF curves

Today we improved alignment of the lens-camera arm. We discovered earlier that this alignment affects the amount of "snowfall" on the scattering images. Looking at the latest 405nm video (see attachment), one can still see snowfall, but it is considerably weaker now and the true scatter image is clearly visible. We took a set of scatter images at certain scattering angles and produced BSDF curves. The shape of these curves has partially to do with the snowfall contribution, but one also has to keep in mind that the mirror quality is much worse than what has been used in the Fullerton measurement. We still need to calibrate these curves. The calibration factor is different for the two images so that you cannot even compare them at the moment except for their shape.

Today we also got the new broadband lens for the camera arm. First measurements show that image quality is better. Playing a bit around with distances between object mirror, lens and image plane, we also found that image quality becomes better when the lens and camera get closer to the mirror (which is only an issue for the 405nm measurement since 633nm and 532nm look very good anyway). So we are thinking to change the camera arm setup to make it much shorter.

Attachment 1: Purple.mp4
Attachment 2: Red.mp4
4   Tue Jul 17 18:32:11 2012 janoschOpticsCharacterizationpurple images

We have the new 405nm laser pointer.  The image to the left shows the scattered light from the red laser, the image to the right scattered light from the purple laser. Both images were taken 30deg with respect to the normal of the mirror surface. Also, we got a new gallon of Methanol. After cleaning the mirror multiple times, the scattered light became significantly weaker. So the purple images look very different from red and green. It could be that the lens that we use to image the mirror surface is the problem since it is specified for the wavelength range 1000nm-1550nm. Could it also be the CCD camera? Anyway, to be sure I will order another broadband lens.

5   Wed Jul 18 18:43:34 2012 janoschOpticsCharacterizationgone with the wind

Here a little purple video. It starts with scattering angle around 15deg and stops at about 80deg.
There are some clear point defects visible especially at small angles.
I will not start to think about some other interesting details of this video before I got the new lens.

Ed: The AVI did not run on Mac. I posted it on youtube. Koji

Attachment 1: Purple.avi
288   Wed Feb 1 15:35:30 2017 GabrieleGeneralDaily Progressexcitation not working - FIXED

My bad, a cable was disconnected.

 Quote: Finally, I tried to excite the disks, but I couldn't get any motion of the optical lever beams. To be investigated, there might simply be some cables disconnected.
2   Fri Jul 13 10:34:35 2012 janoschOpticsCharacterizationcamera image

We were confused a bit about how the camera image changes when you move the arm that holds the camera and lens around the mirror. It seems that scattering centers move in ways that cannot be explained by a misaligned rotation axis. So we wanted to make sure that the mirror surface is actually imaged as we intended to. We generated a white grid with 0.7cm spacing and black background on a monitor. The image that we saw is exactly how we expected it to be. So the image mystery has other reasons.

504   Fri Mar 30 19:12:15 2018 GabrieleGeneralMeasurementsZirconia S1600519 S1600522 S1600565

## 2018-03-30

• 7:10pm in chamber
• S1800634 (Zirconia) in CR1
• S1600519 in CR2
• S1600522 in CR3
• S1600565 in CR4
• 7:12pm roughing pump on
• 7:20pm turbo pump on
418   Fri Aug 18 14:05:36 2017 GabrieleGeneralComputersWorkstation is now up

Reinstalled Debian 8, all packages and CDS software.

Everything seems to be working fine now.

 Quote: While I was working, the network connection went down. I tried to reboot the workstation, but I won't boot anymore. First issue: firmware of network card disappeared. I managed to download it on a USB stick and install it back Second issue: mismatch of NVIDIA graphic card drivers and kernel. Can't start X Working on it...

413   Wed Aug 16 14:35:05 2017 GabrieleGeneralComputersWorkstation is down

While I was working, the network connection went down. I tried to reboot the workstation, but I won't boot anymore.

• First issue: firmware of network card disappeared. I managed to download it on a USB stick and install it back
• Second issue: mismatch of NVIDIA graphic card drivers and kernel. Can't start X

Working on it...

95   Sun Aug 21 13:45:56 2016 GabrieleOpticsDaily ProgressWierd behavior of ring downs and Improved setup

The last two ring downs I measured today showed a weird behavior of the lowest modes:

Although I'm not 100% sure, I suspect this is related to the fact that the beam reflected from the black glass was so close to the beam reflected by the disk that I could see interference.

So I broke vacuum and improved the setup, adding a peek washer below one edge of the black glass, to wedge it. In this way the reflection from the black glass is largely separated: it misses the upper periscope mirror and it is dumped on a black panel (together with the viewport reflection).

I realigned everything, installed back the disk and started pumping down at 1:30pm.

287   Wed Feb 1 15:23:42 2017 GabrieleOpticsNoise huntingWandering line is due to the laser

The wandering line I mentioned in my previous elog, which is spoiling most of the sensitivity, turns out to be power noise of the laser.

I used a Thorlabs PDA100 and a SR785 to measure the power noise out of the laser directly, and saw a huge forest of peaks above 20kHz. Among them, a couple of peaks are moving up and down in frequency very fast. The plot below compares two different times of the Thorlabs HNL210L laser (the new one, 21 mW) with the old JTSU laser we are using for the test setup:

The noise of the new laser is cleary much larger (even after the laser has been on for some time) and non stationary. This is a big issue for us. I will contact Thorlabs to inquire if this behavior is normal.

The attached video file shows the peaks dancing around on the SR785 screen.

Attachment 2: Untitled.avi
186   Mon Nov 14 11:28:33 2016 GabrieleGeneralVacuumViton pads

I added three 1"x1" viton pads below the base plate, and realigned the entire optical system to the horizontal reference

The pads seem to reduce a bit the vibrations in the QPD_X direction, but significantly improve the situation in the QPD_Y direction, see below:

52   Tue Jul 19 17:15:37 2016 GabrieleFacilityDaily ProgressVacuum pressure acquired

[Alena, Gabriele]

We connected the analog output of the vacuum gauge controller to one of the ADC channels. The signal is calibrated so that the pressure is 10^(X3:CR1-PRESSURE_LOGTORR_OUT). Unfortunately the RTG does not know how to compute 10^x...

31   Thu Jul 7 17:44:11 2016 GabrieleFacilityDaily ProgressVacuum chamber tests

[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.

33   Fri Jul 8 15:26:37 2016 AlenaFacilityDaily ProgressVacuum chamber tests

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).

Attachment 1: WP_20160708_12_25_35_Pro.jpg
Attachment 2: WP_20160708_12_25_41_Pro.jpg
36   Mon Jul 11 14:56:45 2016 AlenaFacilityDaily ProgressVacuum chamber tests

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)

Attachment 1: 20160711.png
38   Mon Jul 11 17:04:06 2016 AlenaFacilityDaily ProgressVacuum chamber tests

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
 Quote: 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)

66   Wed Jul 27 15:43:02 2016 GabrieleFacilityDaily ProgressVacuum chamber dismantled and ready for cleaning

[Alena, Gabriele]

As decided at out Red Door meeting, we're going to clean the vacuum chamber and move it to the large table, which will be enclosed in a clean room.

So today we disassembled and packaged the vacuum chamber, which is now ready to be trasnspoted to be cleaned and baked.

331   Fri Mar 10 16:44:13 2017 GabrieleOpticsDaily ProgressUpdated in vacuum periscope of CR0

This afternoon I removed the old periscope from CR0 and installed a new one with finely adjustable mount, like those in the new chamber. I realigned the optical lever to the horizontal refererence.

122   Thu Sep 22 13:39:40 2016 GabrieleOpticsConfigurationUpdated design for the new C.Ri.Me. setup

Today I measured the amount of space available on the table for the new (4-fold) C.Ri.Me. setup. It's 1050 x 1220 mm, with the table hole in it.

So I updated the optical layout to fit into this space, and optimized the telescope to have a beam spot on the QPD of the order of 350 um. The average lever arm length is 1.5 m, so the optical gain will be about 7000 /rad.

Attachment 1: crime_v2.pdf
447   Tue Dec 12 15:35:27 2017 GabrieleGeneralMeasurementsUniversity Wafers substrates (76.2mm/0.5mm) annelaed

## 2017-12-12

Four substrates from University Wafers (76.2mm / 0.5mm) in chamber

• 3:32pm in chamber (CR1 - CR4)
• 3:35pm roughing pump on
• 3:45pm turbo pump on
• Excitations:
• Quiet time before excitation: 1197168131
Quiet time after excitation: 1197168191
• Quiet time before excitation: 1197175421
Quiet time after excitation: 1197175481
• Quiet time before excitation: 1197182711
Quiet time after excitation: 1197182771
• Quiet time before excitation: 1197190001
Quiet time after excitation: 1197190061
• Quiet time before excitation: 1197197291
Quiet time after excitation: 1197197351
• Quiet time before excitation: 1197204581
Quiet time after excitation: 1197204641
• Quiet time before excitation: 1197211871
Quiet time after excitation: 1197211931

409   Tue Aug 15 16:43:58 2017 ZachElectronicsModelingUnchanged Mode Insight

# 2017-08-15

• It appears to me that the major factor limiting the improvement of the modes that either remain equal or diminish is that the original design was already quite good at exciting those modes. As can be seen in the attached plots, the original design is about as well centered over the 5 modes as a rectangle on the x axis can be. As a result, maintaing a constant potential on the ESD it would be difficult to improve the coupled force without specifically tailoring the force profile to a certain mode.
• In order from left to right, the frequencies of the given modes are 14.2 kHz, 16.2 kHz, 16.3 kHz, 23.8 kHz, and 27.4 kHz.

Attachment 1: Double.pdf
Attachment 2: Thin.pdf
Attachment 3: Original.pdf
296   Wed Feb 8 17:01:01 2017 GabrieleOpticsDaily ProgressTwo laser installed, setup aligned

Today I swapped out the 8mW laser and installed two 2.5 mW lasers. I rebuilt the input part of the optical levers and re-aligned everything. See below for a picture of the new setup: red beams are input, yellow beams are output. I also installed a protective screen all around the table, to abvoid any suprios beam to get out.

300   Thu Feb 9 09:30:52 2017 GabrieleOpticsDaily ProgressTwo laser installed, setup aligned

The lasers are behaving well, there is no high noise or wandering lines. The spectrum below is taken in air: that explains the excess of noise in the few kHz region.

 Quote: Today I swapped out the 8mW laser and installed two 2.5 mW lasers. I rebuilt the input part of the optical levers and re-aligned everything. See below for a picture of the new setup: red beams are input, yellow beams are output. I also installed a protective screen all around the table, to abvoid any suprios beam to get out.

415   Thu Aug 17 14:19:04 2017 ZachElectronicsModelingTwo ESD Optimization

# 2017-08-17

• I ran a sweep of the position of the middle ESD to determine the optimal arrangement. From the original geometry I offset the central ESD between -2 mm and 11 mm. From the plots below I conclude that the optimal geometry is the one that is shifted 2 mm to the right of the original design.
• The first plot is the sweep data as a ratio to the data of the current geometry for all modes. The second plot is the root mean square of the eight high frequency modes that change the most over the course of the sweep, those are modes 9, 11, 13, 14, and 17-20. The frequencies of those modes in order are 9.5kHz, 11 kHz, 14 kHz, 16 kHz, 19 kHz, 20 kHz, 21 kHz, and 23 kHz. There is a very apparent peak at 2 mm which is the driving force behind my conclusion that it is the optimal design. The next two plots are the 2mm shifted design and the original design as ratios to the original geometry. The 2mm shifted geometry is much more consistent than the original design, there is a very noticeable minimum in the original design (improvement by a factor of 2) for the 23 kHz mode that is resolved in the shifted design to a factor of 9.
• The final plot are ratios of the two designs relative to each other. I found this plot useful to convince myself that the 2 mm shifted design was better than the original, particularly in the region above 1.5 kHz.

Attachment 1: Two.jpg
Attachment 2: Two.jpg
Attachment 3: RMS.jpg
Attachment 4: 2mm_shifted.jpg
Attachment 5: Sweep_Ratio.jpg
Attachment 6: Dynamic_Modes.jpg
Attachment 7: Sweep_Ratio.jpg
Attachment 8: Comparing.jpg
Attachment 9: 0mm_shifted.jpg
Attachment 10: Comparing.jpg
Attachment 11: 0mm_shifted.jpg
Attachment 13: 2.Dynamic_Modes.jpg
414   Wed Aug 16 16:05:09 2017 ZachElectronicsModelingTwo ESD First test

# 2017-08-16

• I created a model with two ESD's, essentially a combination of my previous two attempts with one ESD on the edge and one closer to the center of the disk. This test was quite successful compared to previous trials, the improvement seems to be on an average of a factor of 10. No modes are weakened by this design. I am going to run a sweep adjusting the central ESD and see what placement is best.
• Attached is an overlay of the force profile and all of the modes. Note that this image is very large, and is useful as a digital reference or very large print only.

326   Thu Mar 2 11:27:47 2017 GabrieleGeneralNoise huntingTurbo pump of CR0 pollutes CR1

The turbo pump of the CR0 chamber runs at 833 Hz. It causes vibrations that pollute the measurements in the CR1-4 chamber. In particular CR1 is extremely sensitive and the line is highly up-converted. It's not clean why CR1 is more sensitive than CR2-3-4.

498   Tue Mar 27 16:37:22 2018 GabrieleGeneralVacuumTurbo pump for test chamber CR0 set point

I changed the set point of the test chamber turbo pump to 666 Hz. This was done by setting the "standby rotation speed" to 80% and enabling the standby condition.

165   Mon Nov 7 11:27:16 2016 GabrieleGeneralVacuumTurbo pump excites some resonance at 58 Hz

I looked into a couple of turbo pump switch on periods, and in both cases when the pump speed hits 58 Hz, a resonance is excited. I'm not sure what's resonating.

Today I let the roughing pump reduce the pressure to a level lower than usual, and this seems to mitigate the effect. The disk wasn't shaking as much as it did in previous pump-downs.

224   Mon Dec 5 10:39:16 2016 GabrieleElectronicsConfigurationTrying to debug GPS time issue

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.

227   Tue Dec 6 09:02:17 2016 GabrieleElectronicsConfigurationTrying to debug GPS time issue

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...

 Quote: 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.

228   Tue Dec 6 10:38:19 2016 GabrieleElectronicsConfigurationTrying to debug GPS time issue

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.

Quote:

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...

 Quote: 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.

229   Tue Dec 6 11:22:58 2016 GabrieleElectronicsConfigurationTrying to debug GPS time issue

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.

Quote:

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.

Quote:

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...

 Quote: 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.

231   Tue Dec 6 16:55:51 2016 GabrieleElectronicsConfigurationTrying to debug GPS time issue

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

232   Wed Dec 7 08:14:05 2016 GabrieleElectronicsConfigurationTrying to debug GPS time issue

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

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

235   Wed Dec 7 16:27:11 2016 GabrieleElectronicsConfigurationTrying to debug GPS time issue

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.

Quote:

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

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

236   Thu Dec 8 09:26:10 2016 GabrieleElectronicsConfigurationTrying to debug GPS time issue

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.

400   Wed Aug 9 15:57:28 2017 ZachElectronicsModelingTriangular Geometry

# 2017-08-09

• I compared the triangular geometry to the original geometry and the excitation was only improved in 7 of the of 20 modes. In four of those modes the improvement factors ranged from almost 2 to over 3 while the other modes where only improved by about 25%. The other 13 modes were diminished drastically, 9 of them where less than half as excited. Given more time it may have been interesting to try and optimize the geometry of a triangular drive, but that would easily take the better part of a week.

303   Fri Feb 10 17:16:28 2017 GabrieleMechanicsDaily ProgressTranslation stage to move retaining rings

This afternoon I installed the picomotor and the translation stage that will be used to move the retaining rings up and down. No partciular problem: I only had to add some small aluminum foil shims between the ear of some rings and the square plate, to make the rings as horizontal as possible.

I tested the motion: with 300000 steps it's possible to move the rings all the way from the parked (down) position, to the up position. I also checked that when the rings are up, I can place four substarates and they fall properly into the alignment groove. Since the maximum speed of the picomotor is 2000 steps/s, it takes 150 seconds to move up and down the ring.

Finally, positive steps means that the rings are moving up, negative that they're moving down.

I raeligned the optical levers to the position I obtained by centering the samples with the rings. I haven't tested the repeatability yet.

304   Sat Feb 11 16:22:26 2017 GabrieleMechanicsDaily ProgressTranslation stage to move retaining rings

The ring motion up and down was not very smooth, again due to friction on the centering pins.

So, after centering the rings using the pins and securing the rings to the translation stage, I removed all pins.

Now the motion up and down is very smooth.

I still have to fine tune the amount of steps that are needed to go up and down.

However, initial tests don't show a good repeatability of the positioning. My main suspect is that the vibration caused by the picomotor cause the disks to slip on the silicon lens. Indeed, when the disks are sitting on the rings, one can clearly hear them "rattle".

 Quote: This afternoon I installed the picomotor and the translation stage that will be used to move the retaining rings up and down. No partciular problem: I only had to add some small aluminum foil shims between the ear of some rings and the square plate, to make the rings as horizontal as possible. I tested the motion: with 300000 steps it's possible to move the rings all the way from the parked (down) position, to the up position. I also checked that when the rings are up, I can place four substarates and they fall properly into the alignment groove. Since the maximum speed of the picomotor is 2000 steps/s, it takes 150 seconds to move up and down the ring.  Finally, positive steps means that the rings are moving up, negative that they're moving down. I raeligned the optical levers to the position I obtained by centering the samples with the rings. I haven't tested the repeatability yet.

237   Thu Dec 8 15:32:04 2016 GabrieleElectronicsConfigurationTiming issue: is it a DAC issue?

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.

Attachment 1: 2016-12-08_14.56.47.jpg
240   Mon Dec 12 14:15:53 2016 GabrieleElectronicsConfigurationTiming issue: is it a DAC issue?

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.

 Quote: 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.

244   Sat Dec 17 06:29:15 2016 ranaElectronicsConfigurationTiming issue: is it a DAC issue?

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.

239   Mon Dec 12 08:42:44 2016 GabrieleGeneralMeasurementsThermoelastic losses in Si sample

Following the model from R. Nawrodt et al. Investigation of mechanical losses of thin silicon flexures at low temperatures, CQG 30 (2013) 115008, I predicted the thermo-elastic losses in the Si sample. The model matches quite well the measurements:

Here are some details on the model, eq. 1 and 2 of the cited paper:

$\phi_{TE}=\frac{\alpha^2 YT}{\rho C_P} \frac{\omega \tau}{1 + \omega^2 \tau^2}$

$\tau = \frac{\rho C_P t_f^2}{\pi^2 k}$

where:

• alpha  = thermal expansion coefficient 2.6e-6/K
• Y = Young's modulus 150 GPa
• T = temperature 300 K
• C_P = specific heat 705 J/kg/K
• rho = density 2329 kg/m^3
• t_f = sample thickness 400 um
• k = thermal conductivity 130 W/m/K

The model is for a cantilever, but it fits well enough for our disk too.

76   Wed Aug 10 10:04:35 2016 GabrieleMechanicsDaily ProgressThe prototype of the disk retain system is here

Yesterday we received the prototype of the disk suspension and retain system. Everything looks good. I checked that the disk fits in the holder, and all dimensions are good. The coil holders are out for winding, so I couldn't test the movimentation yet.

Attachment 3: 2016-08-09_14.18.55.jpg
Attachment 4: 2016-08-09_14.19.02.jpg
ELOG V3.1.3-