LOG-IN
Displaying reports 101-120 of 3272.Go to page Start 2 3 4 5 6 7 8 9 10 End
R&D (Speed meter)
Print this report.
YoheiNishino - 23:13, Wednesday 04 September 2024 (3707)Get code to link to this report
Measurement of the PFD circuit

Nishino,

I measured the response of the new PFD circuit. Input signals are phase-locked sinusoidal waves, generated by Moku:Lab. I scanned the relative phase over 360 degrees. Attached file is the result.

Linear range is wider than the spec sheet of AD9901.

Images attached to this report
3707_20240903095713_pfdresponse.png 3707_20240904161328_20240904231321.png
General (General)
Print this report.
MarcEisenmann - 17:43, Wednesday 04 September 2024 (3709)Get code to link to this report
Comment to robocopy test (Click here to view original report: 3704)

As the C directory of PCI PC is full I moved the Dropbox folder to the D directory.

I modified the robocopy script accordingly.

Don't forget to update the saving folder for all PCI labview scripts to avoid crash.

General (General)
Print this report.
MarcEisenmann - 11:14, Wednesday 04 September 2024 (3708)Get code to link to this report
Comment to robocopy test (Click here to view original report: 3704)

This night it took roughly 2h to perform this automatic back-up.

 

There is also now /purge option that will remove deleted files from the source folders.

I removed the /v and /tee options.

General (General)
Print this report.
MarcEisenmann - 16:08, Tuesday 03 September 2024 (3706)Get code to link to this report
Comment to robocopy test (Click here to view original report: 3704)

The initial version did not work so I had to modify the file (the 'robocopy_test.bat' on PCI pc desktop).

It is working properly so I set up the daily back-up of the dropbox to the NAS BIGFOOT folder.

I used the following parameters :

/e : copy folders and sub-folders

/copy:DATSO : copy data, attributes, timestamps, security and ower infos of all files

/r:5 : retry 5 times to run

/w:5 : wait 5s before new trial

/MT:64 : multi-thread copy

/tee : display output in console (maybe can be erased for the automatic back-up)

/log+:Z:\group\tama300\MIR\Shareslog_ShareName_%date:~-10,2%-%date:~7,2%-%date:~-4,4%.txt : create daily log file

/v : verbose

BIGFOOT (Cavity)
Print this report.
MarcEisenmann - 17:34, Monday 02 September 2024 (3705)Get code to link to this report
possible cavity design

After going through few curved mirrors in TAMA it seems a convenient combination could be a pair of RoC = 0.3m awith R = 99% and cavity length of 0.55m.

All curved mirrors I could find are stored in the large dessicator.

The attached plot shows that we should get about 2mm radius beam 75cm before the cavity where we could place our birefringent sample.

Images attached to this report
3705_20240902105542_beamprop.png
General (General)
Print this report.
MarcEisenmann - 10:11, Monday 02 September 2024 (3704)Get code to link to this report
robocopy test

I set up on PCI a test robocopy script that should automatically copy the folder 'C:\Users\tama3\Dropbox\PCI\robocopy_test' to the NAS folder '\group\tama300\MIR' everyday at 2 in the morning.

I wrote a small script 'robocopy_test' saved on pc desktop and set up a recurring task from windows task scheduler 'Robocopy script'

I'll play a bit with it during this week and if everything goes smoothly I'll set up the back-up of PCI and BIGFOOT pc.

Comments related to this report
MarcEisenmann - 16:08, Tuesday 03 September 2024 (3706)

The initial version did not work so I had to modify the file (the 'robocopy_test.bat' on PCI pc desktop).

It is working properly so I set up the daily back-up of the dropbox to the NAS BIGFOOT folder.

I used the following parameters :

/e : copy folders and sub-folders

/copy:DATSO : copy data, attributes, timestamps, security and ower infos of all files

/r:5 : retry 5 times to run

/w:5 : wait 5s before new trial

/MT:64 : multi-thread copy

/tee : display output in console (maybe can be erased for the automatic back-up)

/log+:Z:\group\tama300\MIR\Shareslog_ShareName_%date:~-10,2%-%date:~7,2%-%date:~-4,4%.txt : create daily log file

/v : verbose

MarcEisenmann - 11:14, Wednesday 04 September 2024 (3708)

This night it took roughly 2h to perform this automatic back-up.

 

There is also now /purge option that will remove deleted files from the source folders.

I removed the /v and /tee options.

MarcEisenmann - 17:43, Wednesday 04 September 2024 (3709)

As the C directory of PCI PC is full I moved the Dropbox folder to the D directory.

I modified the robocopy script accordingly.

Don't forget to update the saving folder for all PCI labview scripts to avoid crash.

R&D (FilterCavity)
Print this report.
MichaelPage - 12:30, Friday 30 August 2024 (3702)Get code to link to this report
Green path stability

I wanted to investigate the weak error signal of the GRMC and its somewhat sensitive response to acoustic noise. Actually I found the SHG has a bit of the same behaviour. I'm not sure what happened, but recently I noted I had to turn the control loop gain way down to avoid oscillation. I probably should have checked the open loop transfer function of both but I got sidetracked by some other thoughts. Anyway it's a bit mysterious why the ideal gain went down for the SHG and GRMC.

Since the SHG temperature was not optimized in a long time, I changed it from 3.163 (174 mW green) to 3.192 (318 mW green). Actually this seems like a bit more, it was supposed to be 280 mW max. Input IR is about 777 mW directly in front of the SHG, compared to 680 mW 3151. Overall SHG efficiency is still 41% though. However, I later noticed that the IR Sensor type power meter (Thorlabs S-121C) measures 655 mW IR at the SHG, while the stick type sensor (S-130C) measures 777 mW. I did a small profile of the temperature vs green.

The green error signal amplitude is a bit weak. However, the green lock PD is very sensitive. Since it locks and outputs stabilized green power to the OPO, maybe I should just keep going and see if the OPO works properly. It seems quite surprising that we can lock despite using 88 MHz IR sidebands that are going through three dichroic mirrors. The 88 MHz signal at GRMC_REFL_RF is about -14.7 dBm. The green lock PD has bandwidth 100 MHz so the frequency doubled green sidebands don't show up in the PD spectrum.

Images attached to this report
3702_20240830053105_shgtemp240830.png
R&D (Speed meter)
Print this report.
YoheiNishino - 16:33, Friday 23 August 2024 (3700)Get code to link to this report
GR beam profile measurement

Nishino,

I measured the beam profile of the green laser before the PCM. The beam widths are {0.091, 0.111} mm for {x, y}, the positions are at z={320, 257} mm from the starting point (z=0).

z=0 is 900 mm away from the PCM. Using these values, I derived the position of two lenses, f150 and f400, at z = 134 mm and 566 mm, achieving the best mode-matching of 93%.

Images attached to this report
3700_20240823092909_profile.png
BIGFOOT (Readout)
Print this report.
ShalikaSingh - 13:51, Wednesday 14 August 2024 (3699)Get code to link to this report
VI for Moku

We can save data from Moku using labview "Complete Integration for MokuGo". We can currently save the voltage data. Averaging exists for this as well.

This MokuGo has 2 channels and we can save both channels simultaneously if required.

BIGFOOT (Readout)
Print this report.
ShalikaSingh - 17:11, Tuesday 13 August 2024 (3698)Get code to link to this report
Interfacing PD to labview

First I tried Connecting NI-SCX1-1000 to labview. Seems this component has been discontinued and there are hence several issues connecting with labview. Bascially, I could't figure it out and I gave up very quickly.

Next, I connected the PD to Moku. 

PD output range is 0-10V. Moku input range is ±25V. It seems for most of PD interfacing, its better and simpler to use Moku. 

I installed Moku drivers to be used in Labview. Moku is now available in "Functions/Liquid Instruments Moku" during VI development.

Moku is connected to Labview using usb connections as mentioned in the  liquid instrument instructions page

On a side not, Moku has two applications, "Waveform Generator" and "Arbitrary Waveform Generator". The former one can generate signal upto ±5V and 20MHz(moku specs), whereras the latter one only can generate upto ±2.5V and 10MHz(much lower than specs). Its better to use "Waveform generator" to be able to easily meet specs. 
 

BIGFOOT (General)
Print this report.
HugoSaintOlive - 07:28, Wednesday 07 August 2024 (3695)Get code to link to this report
ILM Sample measurement PCI

ILM Sample

average = 50
air r = 3 ; sample r = 14
center x= 323.59; y= 156.7210 ; z=60

azi=0

air : Tue, Aug 6, 2024 9-04-34 AM.txt

sample :Tue, Aug 6, 2024 9-13-19 AM.txt

azi=45

air : Tue, Aug 6, 2024 11-14-14 AM.txt

sample :Tue, Aug 6, 2024 11-21-40 AM.txt

azi=15

air : Tue, Aug 6, 2024 1-32-48 PM.txt

sample : Tue, Aug 6, 2024 1-38-53 PM.txt

azi=30

air : Tue, Aug 6, 2024 3-46-54 PM.txt

sample : Tue, Aug 6, 2024 3-58-21 PM.txt

azi=60

air : Tue, Aug 6, 2024 5-53-21 PM.txt

sample :Tue, Aug 6, 2024 5-59-05 PM.txt

azi=75

air : Wed, Aug 7, 2024 7-19-44 AM.txt

sample : Wed, Aug 7, 2024 7-28-12 AM.txt

R&D (Cryogenic)
Print this report.
RishabhBajpai - 07:43, Tuesday 06 August 2024 (3691)Get code to link to this report
Borrowed Ratchet from Tama

I borrowed Ratchet and couple of hex bits for today's work. I will return in by end of the day.

Images attached to this report
3691_20240806004326_ratchet.jpeg
BIGFOOT (General)
Print this report.
HugoSaintOlive - 16:49, Monday 05 August 2024 (3690)Get code to link to this report
PCI Measurement QWP test

we still have som issue ith 50 average so we try with 100

QWP
average = 100
air r = 3 ; sample r = 5
center x= 323.59; y= 154.375 ; z=60

azi = 0

air ; Mon, Aug 5, 2024 10-03-06 AM

sample : Mon, Aug 5, 2024 10-14-33 AM

azi = 15

air ;Mon, Aug 5, 2024 10-46-54 AM

sample : Mon, Aug 5, 2024 10-57-28 AM

azi =30

air ;Mon, Aug 5, 2024 11-28-22 AM

sample : Mon, Aug 5, 2024 11-39-02 AM

azi = 45

air ; Mon, Aug 5, 2024 12-14-31 PM.txt

sample: Mon, Aug 5, 2024 12-26-25 PM.txt

azi=60

air : Mon, Aug 5, 2024 12-56-13 PM.txt

sample :Mon, Aug 5, 2024 1-07-41 PM

azi = 75

air : Mon, Aug 5, 2024 4-05-47 PM.txt

sample ; Mon, Aug 5, 2024 4-16-33 PM.txt

 

R&D (FilterCavity)
Print this report.
MichaelPage - 23:32, Friday 02 August 2024 (3687)Get code to link to this report
TAMA IRMC and loop stability issues

I managed to recover the "good" error signal of GRMC. It turns out that it actually did have something to do with the optical part, or rather the SHG output oscillation. I didn't turn down the gain on the SHG quite enough, so residual power oscillation made its way to the green error signal port (GRMC REFL RF), visible on the GRMC EPS2 OUT when the MZ is not locked to stabilize power. After adjusting appropriately, the GRMC error signal became the usual PDH with about 1 Vpk. I locked GRMC/MZ then checked the output power with the power meter - it sits fairly stably at 26.3 mW when the MZ servo is set to 4.2 offset, which is consistent with our usual work. The GRMC output power also had some oscillation at the nominal good gain - I had to reduce it from 3 to 1.4. While I am not certain yet if this is a byproduct, the GRMC output power is extremely sensitive to acoustic noise. Tapping foot makes a wave in the output. I don't entirely know if it is SHG, MZ, phase shifter or GRMC. Maybe can try also tweaking MZ gain and see if that fixes it or makes other things worse.

Initially I couldn't see error signal for IRMC, but the cable was disconnected. However, the error signal is not normal. It looks like a low detuning/transmission signal for PDH rather than the more familiar high detuning reflective form. I checked that it goes to zero when blocking IRMC REFL so it wasn't a misconnection to a transmission PD. I tried connecting some longer cables to change the demodulation phase but it doesn't change much. Then I found that the IRMC DEMOD LO signal was changed from DDS1 DAC1 (has a splitter which also goes to SHG DEMOD) to DDS2 DAC0, which right now is redundant (previously used for GRMC EOM which was removed from the locking scheme). This has a good intention since we don't have to bother with fudging the cable length or using an IQ demodulator. I checked the LO strength and DDS2 DAC0 is quite weak at -9.7 dBm. I checked the splitter channel DDS1 DAC1 (4.5 dBm) and tried using it as IRMC DEMOD LO but the error signal was still quite bad. IRMC will also not lock. 

I don't know whether or not to be concerned about DDS2 signal strength. GRMC DEMOD and the main 88 MHz EOM all come from weak signal ports but are RF amplified to about 0-5 dBm level. There are some RF amplifier ports +14 dBm that are unused, labelled "NO USE". I didn't check if that means they were broken or just unused. Next time.

R&D (FilterCavity)
Print this report.
MichaelPage - 22:03, Thursday 01 August 2024 (3686)Get code to link to this report
TAMA GRMC issues

Based on some guess I had about the oscilloscope voltage of the IR transmission increasing, I set the Threshold to 10x the value of what I wanted it to be (500 mV -> 5V). I tried to check if the oscillating lock point was due to the gain being too high causing control loop resonance to appear in the cavity length, but somehow by just touching the gain knob I was able to get the SHG to lock normally. Output green is 250 mW which is nominal.

I realigned the MZ to GRMC to get good mode matching. Not much issue. I checked the error signal and the base level has some large 1 Vpk oscillation at about 8.7 kHz. The spurious oscillation seems to be coming from the output of the GRMC mixer in the "cable management box" - the spectral peak is not present from the L input (GRMC DEMOD DDS2 DAC2) or the R input (GRMC REFL RF). It also wasn't present in IRMC ERR or OPO ERR. It was getting late so I didn't have time to check if it was bad connection or some other reason.

The PLLs managed to stay locked for 32 hours. So it seems not much problem there. But I did notice that on one occasion tapping the cables for the GRMC problem above cause a bit of noise to show up in CC.

I turned off the lasers.

BIGFOOT (General)
Print this report.
HugoSaintOlive - 11:34, Thursday 01 August 2024 (3678)Get code to link to this report
PCI Manipulation

Realignement of the beam after some issue with the polarizer alignement :

start : x=323.565  ; y= 64.3750; z=60

distance between blade and last mirror = 146mm

vertical cut of the beam ; x=314  ; y= 100; z=20

horizontal cut of the beam ; x=360  ; y= 180; z=20

 

max DC = 0.234V

 

y(166.500)=  9.14e-5  = y(146.943)

x(313.700)  = 7.14e-5 = x(333.480)

--> CENTER : x=323.59 ; y =156.721

R&D (Cryogenic)
Print this report.
RishabhBajpai - 11:09, Thursday 01 August 2024 (3685)Get code to link to this report
Cleanup

In prepartion for installing the black out curtain and moving the Al bar, I removed all the optics form the table (Fig.1). They are now stroed in the big desiccator (fig .2).

I also tried rearranging the Thorlabs lens case but gave up since it was all mixed up.

During this work, I notice most of the the pedastals and mirror mounts I stored inside the box labelled cryogenic cavity had disapperead (fig.3).

Images attached to this report
3685_20240801040740_1.jpg 3685_20240801040752_2.jpg 3685_20240801040911_3.jpg
R&D (FilterCavity)
Print this report.
MichaelPage - 21:56, Wednesday 31 July 2024 (3684)Get code to link to this report
TAMA SHG issues

After recovering PLLs I hoped that everything would go smoothly to recover squeezing so of course it didn't.

The alignment of SHG is sufficient but not great. I turned on DDS1 DAC1 (SHG/IRMC demod) and checked the phase for the error signal. It seems fine, not much (if any) change from previous phase and 4.88Vpk signal. However, when I locked, there is oscillation of the output power (IR transmission). Specifically, it oscillates at about 5.5 kHz, max ~ 1.9 V, min ~ 1.5 V (0.4 Vpk). For green, the power meter reads 210 mV which is roughly correct but the SHG temperature hasn't been optimized for a long time so it should be closer to 280 mV. I do not think the cause of this oscillation is mechanical since the lowest SHG resonance is about 7 kHz (Yuhang thesis fig 4.7). Likewise it shouldn't be temperature because temperature is slow to respond. There isn't any of this frequency in the demodulation LO from the DDS board (DDS1 DAC 1 into spectrum analyzer). It seems like a recent issue between June and now, possibly due to the lightning strike power outage in Mitaka a couple of weeks ago.

Marc and Logan adjusted the polarization to get rid of HOM splitting when they reconnected electrical things. Indeed I just did some other check - the BSF10C that goes to the transmission DCPD has significantly smaller reflection for p-pol than s-pol, and indeed at the set polarization the total power at the DCPD is minimized (SHG requires p-pol infrared). So the HWP is at the correct place (~ 195 degrees). Actually looking through some of my old photos, during Yuhang's New Years visit it was at 120 degrees - I have no idea why. Rotating the polarizer can reduce the oscillation but it also reduces the transmitted power, and besides it should have already been the correct setting anyway.

Peak optical power at the RFPD was about 3 mW (power meter MAX reading method), which is maybe a little bit low (3.6 mW before). The signal from the (amplified) DCPD on the oscilloscope (coming from TRANSMISS IN) is much larger now than what it was before, even with the gain on 0 dB. It was 550 mV from my old pictures at 30 dB, but is now 1.7 V at 0 dB. This 1.70 V on the DCPD is also the average value of the oscillating locked IR transmission as noted above. Another strange thing is that when I checked the lock threshold it seemed to be at a very large (i.e. not reasonable) value > 1.7 V. Previously it was set at 250 mV (a bit less than half of 550 mV). Did this have something to do with the power outage? I don't know how there is more DCPD voltage for probably similar input power, with the amplification turned down.

Eventually I could not lock SHG anymore. I'm not sure what is the problem right now. I will guess at some items to check:

  • Main laser temperature and current
  • Electrical connections, especially related to SHG servo
  • Badly behaved cables
  • DDS output for EOM
  • Threshold and Gain knob vs output behaviour on SHG servo

I left both PLLs locked to see if they stay locked overnight.

R&D (FilterCavity)
Print this report.
MichaelPage - 18:38, Wednesday 31 July 2024 (3683)Get code to link to this report
Comment to Recovery of (probably) stable TAMA PLL lock (Click here to view original report: 3681)

Both PLLs maintained lock for 5+ hours. The weird ppol issue went away (maybe laser temperature stabilizing). Next up - checking stability of squezing coherent control.

R&D (FilterCavity)
Print this report.
MichaelPage - 15:48, Wednesday 31 July 2024 (3682)Get code to link to this report
Comment to Recovery of (probably) stable TAMA PLL lock (Click here to view original report: 3681)

I checked again. Both PLLs unlocked overnight. The laser temperature drifted down for the ppol (maybe 50 MHz equivalent) and also down for the CC (again maybe 50 MHz equivalent). 

I relocked both of them. The ppol one had a bit of weird behaviour where it does some kind of twitchy unlock relock behaviour - it skips maybe one MHz away from the lock point but then is quickly caught again. I reloaded the PLL settings (Analog Devices ADF4002 SDP board black) and turned on the Charge Pump Gain setting. I'm not entirely sure if that fixed it but I left for lunch, came back to TAMA 90 minutes later and both PLLs were still locked. Maybe I can turn up the timeout delay on the ppol too. I think fiddling with these settings too much may change the phase noise but I will check that after I recover squeezing. Perhaps there could also be a bit more optimization with ppol mutual polarization matching and laser to fiber alignmnet but for now it's serviceable. Anyway at the very least I think I have confirmed that there is no major stability issue with either PLL loop on its own. Now we see if that is maintained for CC1 and CC2 on squeezing.