40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 138 of 341  Not logged in ELOG logo
IDdown Date Author Type Category Subject
  10213   Wed Jul 16 01:54:25 2014 NichinUpdateGeneralWork plan for next week

1) Debugging transimpedance calculations in the PDFR

Requires presence of an expert whenever I get inside the lab to take DC measurements or check the illuminating fibers.

2) Creating and incorporating canonical data plots with every measurement of PDFR.

3) Transfer function fitting for transimpedance

4) Improve the Spectrum analyzer scan scripts as mentioned in my elog.

  10212   Wed Jul 16 01:46:41 2014 NichinUpdateElectronicsTest run of PDFR system

A test run was conducted on the PDFR system last afternoon and transimpedance plots were generated for 6 of the PDs. The laser was shut down after the test run.

I have not verified (yet) if the transimpedance values indicated by the plots are correct or not. The values mostly look INCORRECT. But the peaks are exactly where they need to be. *phew!*

Reasons: Incorrect calibration, Light other than from the PDFR system fibers on the PDs

Will have to work on debugging all this.

Attachment 1: PDFR_testRun_15-07-2014.pdf
PDFR_testRun_15-07-2014.pdf PDFR_testRun_15-07-2014.pdf PDFR_testRun_15-07-2014.pdf PDFR_testRun_15-07-2014.pdf PDFR_testRun_15-07-2014.pdf PDFR_testRun_15-07-2014.pdf
  10211   Wed Jul 16 01:35:16 2014 KojiSummaryLSCPython Wavelet peak finding for dramatic ALS - Red Resonance finding speedup

From the last plot:

- Subtracting the offset of 0.0095, the modulation depth were estimated to be 0.20 for 11MHz, 0.25 for 55MHz

- Carrier TEM00 1.0, 1st order 0.01, 2nd order 0.05, 3rd order 0.002, 4th order 0.004

==> mode matching ~93%, dominat higher order is the 2nd order (5%).

Eric: now we have the number for the mode matching. How much did the cavity round-trip loss be using this number?

  10210   Wed Jul 16 01:27:01 2014 NichinHowToComputer Scripts / ProgramsHP8591E spectrum analyzer remote scan

The script for running continuous scans on HP 8591E spectrum analyzer is located at scripts/general/netgpibdata/HP8591E_contdScan.py

Give the file HP8591E_param.yml as an argument when running the script. This contains the sweep parameters: Start and stop frequencies along with the place where the plot is stored as a PDF.

The default PDF is located on the Desktop and is named HP8591E_View.pdf     Open this using okular and then run the script.  (Okular pdf viewer automatically reloads the PDF as and when a new one is created)

What the script does:

1) Set the start and stop frequencies as given in the .yml file

2) Take a data trace and plot it in a PDF.

3) Repeat taking traces and update the PDF. Untill Ctrl+C is pressed (PDF refresh rate: approximately every 3 seconds )

4) Exit smoothly after the keyboard interrupt.

Other details:

This spectrum analyzer is connected to a GPIB - Ethernet controller that is configured as santuzza.martian (192.168.113.109)

I have currently stolen the wireless modem from the spectrum analyzer inside the lab (vanna.martian) and using it for this one. *poker face*

To improve:

Get the plot to show where the two biggest peaks are located. Currently it recognizes only the biggest one.

Possibly have makers on the two peaks.

PFA a sample pdf

Attachment 1: HP8591E_View.pdf
HP8591E_View.pdf
  10209   Wed Jul 16 01:18:02 2014 ranaSummaryLSCPython Wavelet peak finding for dramatic ALS - Red Resonance finding speedup

New script called scripts/ALS/findRedResonance.py finds the IR resonance in less than 20 seconds.

  1. Do a ~2 FSR scan of the arm over 10 seconds using the Phase Tracker servo offset ramp. (dt = 10 s)
  2. Load the frame data for the TR_OUT and the Phase Tracker phase. (dt = 2 s)
  3. Use Python (modern) SciPy to find all peaks with moderate SNR (dt = 3 s)
  4. Take the top 3 peaks (all presumably TEM00) and choose the one closest to zero and go there.

The above is the gist of what goes on, but there were several issues to overcome to get the code to run.

  1. None of our workstations have a modern enough Python distro to run either the ipython notebooks or the new SciPy with wavelets, so I installed Anaconda Python in the controls home directory.
  2. In order to get the peak finder function to work well I gave it a range of peak widths to look for. If we change the speed of the ALS scan by more than 3x, we probably have to change the width array in the function.
  3. I've used the find_peaks_cwt function in SciPy. This uses a Ricker ('Mexican Hat') wavelet to find peaks by doing multi-res transforms and looking for ridges in the wavelet space (I think)
  4. To make the code run fast, I downsample from 16 kHz to 1 kHz right at the top. Would be better if we had downsampling in v2 of the getData function.

 

Attachment 1: findRedResonance.pdf
findRedResonance.pdf
  10208   Wed Jul 16 01:04:09 2014 JenneUpdateLSCData for DARM on sqrtInv investigation

I realized while I was looking at last night's data that I had been doing CARM sweeps, when really I wanted to be doing DARM sweeps.  I took a few sets of data of DARM sweeps while locked on ALSdiff.  However, Rana pointed out that comparing ALSdiff to TRX-TRY isn't exactly a fair comparison while I'm locked on ALSdiff, since it's an in-loop signal, so it looks artificially quiet. 

Anyhow, I may consider transitioning DARM over to AS55 temporarily so that I can look at both as out-of-loop sensors. 

Also, so that I can try locking DARM on DC transmission, I have added 2 more columns to the LSC input matrix (now we're at 32!), for TRX and TRY.  We already had sqrt inverse versions of these signals, but the plain TRX and TRY were only available as normalization signals before.  Since Koji put in the facility to sqrt or not the normalization signals, I can now try:

Option 1:  ( TRX - TRY ) / (TRX + TRY)

Option 2:  ( TRX - TRY ) / sqrt( TRX + TRY )

DARM does not yet have the facility to normalize one signal (DC transmission) and not another (ALS diff), so I may need to include that soon.  For tonight, I'm going to try just changing matrix elements with ezcastep.

Since I changed the c1lsc.mdl model, I compiled it, restarted the model, and checked the model in.  I have also added these 2 columns to the AUX_ERR sub-screen for the LSC input matrix.  I have not changed the LSC overview screen.

  10207   Tue Jul 15 22:23:51 2014 AndresUpdate40m Xend Table upgradeScan the Xarm for the mode matching

 Nick and I with the help of Jenne scan the green light when the cavity is unlocked. Nick placed a Beam dump on the IR so that we can just scan the green, but it was removed as soon as we finished with the measurement. I'm working on the calculation, and i'll be posted solution tonight.

  10206   Tue Jul 15 21:43:28 2014 JenneUpdateLSCQPDs back

I removed the dumps in front of the trans QPDs.  The Yend QPD needed re-normalization, so I did that.

  10205   Tue Jul 15 18:39:04 2014 HarryUpdateGeneralWeekly Plan (7.16.14)

 The Past Week

 

Attempted to design coupling telescope, turned out waist measurement was still off. Took another waist measurement, this time more reasonable.

Used recent waist measurement to actually design a coupling system to couple NPRO light into Panda PM980 fibers (see recent elog)

The Next Week

Assemble fiber coupling system

Measure coupling efficiency, ensure it's at least 60%

Begin measuring Polarization Extinction ratio

Materials

 

PLCX lens with f = 0.25m ------> status: here

Fiber Coupled Powermeter//PD ------> status: unknown (have any laying around?)

Quarter Wave Plate, Polarizing Beamsplitter, Photodiodes ------> status: here

other components from original razorblade measurement  setup

  10204   Tue Jul 15 18:26:40 2014 HarryUpdateGeneralBeam Waist, Telescope, and Fiber Coupling

 Goal

To design an optical setup (telescope / lens) to couple 1064nm NPRO light into PANDA PM980 fibers in order to characterize the fibers for further use in the frequency offset locking setup.

Design

 fiberTestingSetup.png

Calculations

 The beam waist of the NPRO was determined as 233um 6cm in front of the NPRO. This was used as the seed waist in ALM.

The numerical aperture of the fiber was given as 0.12, which allowed me to calculate the maximum angle of light it would accept, with respect to the optical axis, as NA = sin(theta) where theta is that angle.

Given that the coupler has a focal length of 2mm, I used the formula r = f * tan(theta), to yield a "target waist" for efficient coupling into the fiber. This ended up being 241.7um.

Since there was not a huge difference between the natural beam width of the NPRO and our target waist, I had no need for multiple lenses.

I used 230um as a target waist for a la mode, to leave myself some room for error while coupling. This process gave me a beam profile with a lens (f=0.25m), and a target waist of 231um, located 38.60cm from the coupling lens

I have attached ALM code, as well as the beam profile image. Note that the profile takes zero to be the location of the NPRO waist.

fiberTestingCouplingDesign.png

Next Steps

 

After this setup is assembled, and light is coupled into the fibers, we will use it to run various tests to the fiber, for further use in FOL. First of all, we wish to measure the coupling efficiency, which is the purpose of the powermeter in the above schematic. We will measure optical power before and after the fibers, hoping for at least ~%60 coupling. Next is the polarization extinction ratio measurement, for which we will control the input polarization to the fibers, and then measure what proportion of that polarization remains at the output of the fiber. 

Attachment 3: fiberTesting.zip
  10203   Tue Jul 15 17:34:01 2014 manasaUpdatePSLproposing AOM re-alignment

I am going to tweak the alignment of the beam into the AOM (before the PMC) tomorrow morning. If anybody has any objections to this, please raise a red flag.

Proposed alignment procedure:

1. Reduce PSL power to say 10% 

2.  Since the AOM is not on any sort of a mechanical stage, I will have to just play around carefully until I see a maximum power rejection into first order.

I am assuming that moving the AOM is not going to affect the input pointing because all these activities are happening before the PMC. So as long as I have the output beam from the AOM aligned to the PMC at the end, everyone should be happy.

  10202   Tue Jul 15 12:36:17 2014 NichinUpdateElectronicsRF cables rerouted

Quote:

 

I have not connected them to the RF switch yet. ( until I figure out how to get both the switches working properly)

 I went into the lab and connected the RF cables to the Mux. Will take measurements for each PD henceforth.

  10201   Tue Jul 15 11:04:05 2014 SteveUpdatesafetysafety glasses must be worn all times!

This is the third safety glasses that I found laying around in the IFO lab lately. Safety glasses must be worn ALL times in the IFO room!

This rule is essential for your protection! Please do not enter if you can not put up with this regulation!

 

 

Attachment 1: safetyglasses.jpg
safetyglasses.jpg
  10200   Tue Jul 15 01:41:43 2014 JenneUpdateLSCData for DARM on sqrtInv investigation

I took some data tonight for a quick look at what combinations of DC signals might be good to use for DARM, as an alternative to ALS before we're ready for RF.

I had the arms locked with ALS, PRMI with REFL33, and tried to move the CARM offset between plus and minus 1.  The PRMI wasn't holding lock closer than about -0.3 or +0.6, so that is also a problem.  Also, I realized just now that I have left the beam dumps in front of the transmission QPDs, so I had prevented any switching of the trans PD source.  This means that all of my data for C1:LSC-TR[x,y]_OUT_DQ is taken with the Thorlabs PDs, which is fine, although they saturate around arm powers of 4 ever since my analog gain increase on the whitening board.  Anyhow, the IFO didn't hold lock for much beyond then anyway, so I didn't miss out on much.  I need to remember to remove the dumps though!!

Self:  Good stuff should be between 12:50am - 1:09am.  One set of data was ./getdata -s 1089445700 -d 30 -c C1:LSC-TRX_OUT_DQ C1:LSC-TRY_OUT_DQ C1:LSC-CARM_IN1_DQ C1:LSC-PRCL_IN1_DQ

  10199   Tue Jul 15 01:31:13 2014 AkhilSummaryElectronicsTiming Issues of Mini Circuits UFC-6000: Solved

The attached are the PSD plots with improved FC timing(with the same code as in http://nodus.ligo.caltech.edu:8080/40m/10151). More plots(Phase and PSD) to follow.

 

 

 

Attachment 1: qnoise.png
qnoise.png
Attachment 2: qnoise.pdf
qnoise.pdf
  10198   Tue Jul 15 00:16:52 2014 JenneUpdateSUSPRM significantly pitched

I'm starting to lock for the night, and I noticed that PRM is very, very pitched.  Why?  The PRM pitch slider is 5 full integer units higher than the backup (and the backup value is about where I like it, around -0.2).

I am not aware of any scripts that touch the PRM slider values.  The PRM ASS (which I haven't used in ages) offloads the biases to the SUS screen fast channels, so even if someone turned that on and then saved the values, it wouldn't leave the PRM so very, very misaligned.

I have restored it, and relocked the PRMI, so all is well, but it's very weird to have found it so misaligned.

  10197   Mon Jul 14 17:51:34 2014 NichinUpdateComputer Scripts / ProgramsMEDM for PDFR system

14.pngA

 Successfully completed the rudimentary GUI for PDFR system. (users/nichin/PDFR)

Pressing any of the buttons above runs the script that does the following:

1) Change RF mux channel to the required one.

2) Frequency sweep on the network analyzer. The common sweep parameters are in a file named param_NWAG4395A.yml . PD specific parameters are in param_[PD name].yml in their respective folders

3) The transimpedance is calculated and the plot is saved as PDF in the respective folder for the PD. Each set of measurement data and plot is in a timestamped subfolder.

Further work:

To take transimpedance readings for each PD and create a canonical set of data that can be used to compare with data obtained for every measurement run.

  10196   Mon Jul 14 16:51:07 2014 NichinUpdateElectronicsMartian table updated, Named server restarted

 [Nichin, Jenne]

The martian lookup tables are located at /etc/bind/zones/martian.db  and etc/bind/zones/rev.113.168.192.in-addr.arpa

Jenne updated these to include santuzza.martian  192.168.113.109

 

 

The method to restart named server given at  https://wiki-40m.ligo.caltech.edu/Martian_Host_Table  also does not work.

I restarted it using  >sudo /etc/init.d/bind9 restart

The named server is now updated and works fine. :)  I will update the 40m wiki now.

  10195   Mon Jul 14 16:19:41 2014 AndresUpdate40m Xend Table upgradeTook the measurement for the Mode Matching

 Nick and I measured the reflected power of the green light in locked and unlocked. I'm working on the calculation of the mode matching. Tonight, I'll be posted my calculation I'm still working on it.

JCD:  Andres forgot to mention that they closed the PSL shutter, so that they could look at the green light that is reflected off the harmonic separator toward the IR trans path.  Also, the Xarm (and the Yarm) were aligned to IR using the ASS, and then ASX was used to align the green beam to the cavity.

  10194   Mon Jul 14 14:28:27 2014 KojiSummaryElectronicsTiming Issues of Mini Circuits UFC-6000: Solved

Looks good. Now you have the internal timer to verify the external clock.
If you can realize the constant rate sampling without employing the external clock, that's quite handy.

  10193   Mon Jul 14 13:03:23 2014 AkhilSummaryElectronicsTiming Issues of Mini Circuits UFC-6000: Solved

Main Problem:

The frequency counter (FC) takes in an analog RF input(signal) and outputs the frequency of the signal(Ranging from 1 MHz- 6000 MHz) in the digital domain (into a processor). The FC samples the data with a given sample rate( user defined) which ranges from 0.1 s to 1 s(faced problems in fixing this initially).  For data acquisition, we have been using a Raspberry Pi(as a processor) which is connected to the martian network and can communicate with the computers inside the 40m.  The ultimate challenge which I faced( and been knocking my head off from past two-three weeks) is the synchronization of clocks between the Raspberry Pi and the FC i.e the clock which the FC uses to sample and dump data( every 'x' s) and the clock inside the raspberry pi( used  in the loop to wait for a particular amount of time the frequency counter takes to dump successive data).

 

Steps Taken:

  • To address this problem, first I added an external clock circuit which monitors the Raspberry Pi and the FC to dump and read data at a particular rate(which is equal to the sampling rate of the FC)In detail: http://nodus.ligo.caltech.edu:8080/40m/10129. 
  • While doing so, at first the level trigger algorithm was used which means that the external clock frequency was half as that of  the reciprocal of the sampling rate and a trigger was seen every time the level shifts from +DC to -DC(of the external square wave).
  • But this did not completely mitigate the issues and there were still few issues on how quickly the ADC reads the signal and R Pi processes it.
  • To minimize these issues completely, an edge trigger algorithm which detects a pos edge(rising)  of the clock was used. The clock  frequency is now equal to the reciprocal of the sampling rate. This algorithm showed better results and greatly minimized the drift of the sampling time.

Psuedo Code(code attached):

open device : FC via USB-HID;

open device : ADC via I2C;

always(for t= recording time):

            read data from ADC(external clock);

            if pos edge detected:

                    read data from FC and store it in a register;

             else read data from ADC;

end

write data stored in the register to a file( can be an Epics channel or a text file);

 

Results:

The attached are the plots showing the time between samples for a large number of samples taken for different sampling times of the FC. The percentage error is the percentage of standard error in the timing between two samples for the data for the entire measurement. It can be inferred that this error has been cut down to the order of ms.

 

To do next:

  • I have started taking phase measurements( analysis and plots will follow this elog) and also the PSD plots with the improved timing characteristics.

 

 

 

             

 

Attachment 1: 0.2timinganalysis.png
0.2timinganalysis.png
Attachment 2: 0.3timinganalysis.png
0.3timinganalysis.png
Attachment 3: 0.5timinganalysis.png
0.5timinganalysis.png
Attachment 4: 1stiminganalysis.png
1stiminganalysis.png
Attachment 5: pdf.zip
  10192   Mon Jul 14 12:49:07 2014 NichinUpdateElectronicsNew Prologix GPIB-Ethernet controller

Quote:

Quote:

I have configured a NEW Prologix GPIB-Ethernet controller to use with HP8591E Spectrum analyzer that sits right next to the control room computers.

Static IP: 192.168.113.109

Mask: 255.255.255.0

Gateway: 192.168.113.2

I have no clue how to give it a name like "something.martian" and to update the martian host table (Somebody please help!!) 

The instructions for adding a name to the martian DNS table are in the wiki page that I pointed you to:

https://wiki-40m.ligo.caltech.edu/Martian_Host_Table

The instructions at https://wiki-40m.ligo.caltech.edu/Martian_Host_Table   are outdated!

The name server configuration is currently at /etc/bind/zones/martian.db [ source: elog:10067 ]

 

Anyway, I need superuser access to edit the files, which I don't have. Even if I did know the password, I don't think it's a good idea for me to be messing around. So any of the 40m folks please update the martian table to include:

santuzza.martian  192.168.113.109

 

  10191   Sun Jul 13 17:06:35 2014 AndresUpdate40m Xend Table upgradeXarm Table Upgrade Calculation and Diagrams of possible new table layout

 Current Mode Matching and Gouy Phase Between Steering Mirrors

We found in 40m elog ID 3330 ( http://nodus.ligo.caltech.edu:8080/40m/3330a documentation done by Kiwamu, where he measured the waist of the green. The waist of the green is about 35µm. Using a la mode, I was able to calculate the current mode matching, and the Gouy phase between the steering mirrors. In a la mode, I used the optical distances,which is just the distance measured times its index of refraction. I contacted someone from ThorLabs (which is the company that bought Optics For Research), and that person told that the Faraday IO-5-532-LP has a Terbium Gallium Garnet crystal of a length of 7mm and its index of refraction is 1.95. The current mode matching is 0.9343, and the current Gouy phase between steering mirrors is 0.2023 degrees. On Monday, Nick and I are planning to measure the actual mode matching. The attached below is the current X-arm optical layout. 

 

 

Calculation For the New Optical Layout

 

Since the current Gouy phase between the steering mirror is essentially zero, we need to find a way how to increase the Gouy Phase. We tried to add two more lenses after the second steering mirror, and we found that increasing the Gouy phase result in a dramatically decrease in mode matching. For instance, a Gouy phase of about 50 degrees results in a mode matching of about .2, which is awful. We removed the first lens after the faraday, and we added two more mirrors and two more lenses after the second steering mirror. I modified the photo that I took and I place where the new lenses and new mirrors should go as shown in the second pictures attached below. Using a la mode, we found the following solution:

 label                         z (m)            type                       parameters         

 -----                          -----              ----                        ----------         

 lens 1                       0.0800          lens                      focalLength: 0.1000

 First mirror              0.1550          flat mirror            none:            

 Second mirror         0.2800          flat mirror            none:            

 lens 2                      0.4275           lens                      focalLength: Inf   

 lens 3                     0.6549            lens                      focalLength: 0.3000

lens 4                      0.8968            lens                      focalLength: -0.250

Third mirror           1.0675            flat mirror            none:            

Fourth mirror         1.4183            flat mirror            none:            

lens 5                      1.6384            lens                     focalLength: -0.100

Fifth mirror            1.7351            flat mirror           none:            

Sixth mirror           2.0859            flat mirror           none:            

lens 6                     2.1621            lens                     focalLength: 0.6000

ETM                      2.7407            lens                    focalLength: -129.7

ITM                       40.5307          flat mirror          none:             

The mode matching is 0.9786. The different Gouy phase different between Third Mirror and Fourth Mirror is 69.59 degrees, Gouy Phase between Fourth and Fifth 18.80 degrees, Gouy phase between Fifth and Sixth mirrors is 1.28 degrees, Gouy phase between Third and Fifth 88.38 degrees, and the Gouy phase between Fourth and Sixth is 20.08 degrees. Bellow attached the a la Mode code and the Plots.

 

 

Plan for this week

I don't  think we have the lenses that we need for this new setup. Mostly, we will need to order the lenses on Monday. As I mention, Nick and I are going to measure the actual mode matching on Monday. If everything look good, then we will move on and do the Upgrade.

 

Attachment 1: CurrentOpticalLayout.png
CurrentOpticalLayout.png
Attachment 2: NewSetUp.PNG
NewSetUp.PNG
Attachment 3: AlaModeSolutionplots.png
AlaModeSolutionplots.png
Attachment 4: EntireScaleRangeAlaModeSolution.png
EntireScaleRangeAlaModeSolution.png
Attachment 5: NewXarmOptimizationFromFaraday.m
close all
clear all
% In this code we are using a la mode to optimatize the mode matching and
% to optimatize the Gouy phase between mirror 1 and mirror 2. All the units
% are in meter

w0=(50*1e-6)/sqrt(2); % The Waist of the laser measured after SHG
z0_laser=-0.0083; % position measured where the waist is located 
lamb= 532*10^-9; % wavelength of green light in mm
lFaraday=.0638; % Length of the faraday
... 209 more lines ...
  10190   Sun Jul 13 11:37:36 2014 JamieUpdateElectronicsNew Prologix GPIB-Ethernet controller

Quote:

I have configured a NEW Prologix GPIB-Ethernet controller to use with HP8591E Spectrum analyzer that sits right next to the control room computers.

Static IP: 192.168.113.109

Mask: 255.255.255.0

Gateway: 192.168.113.2

I have no clue how to give it a name like "something.martian" and to update the martian host table (Somebody please help!!) 

The instructions for adding a name to the martian DNS table are in the wiki page that I pointed you to:

https://wiki-40m.ligo.caltech.edu/Martian_Host_Table

  10189   Fri Jul 11 22:28:34 2014 ChrisUpdateCDSc1auxex "Unknown Host"

Quote:

c1auxex has forgotten who it is.  Slow sliders for the QPD head were not responding, so I did a soft reboot from telnet. The machine didn't come back, so I plugged the RJ45-DB9 cable into the machine and looked at it through a minicom session.  When I key the crate, it gives me an error that it can't load a file, with the error code 0x320001.  Looking that up on a List of VxWorks error codes, I see that it is:    S_hostLib_UNKNOWN_HOST (3276801 or 0x320001)

I'm not sure how this happened.  I unplugged and replugged in the ethernet cable on the computer, but that didn't help.  Rana is going in to wiggle the other end of the ethernet cable, in case that's the problem.  EDIT:  Replacing the ethernet cable did not help.

Former elogs that are useful:  10025, 10015

EDIT:  The actual error message is:

boot device          : ei                                                      
processor number     : 0                                                       
host name            : chiara                                                  
file name            : /cvs/cds/vw/mv162-262-16M/vxWorks                       
inet on ethernet (e) : 192.168.113.59:ffffff00                                 
host inet (h)        : 192.168.113.104                                         
user (u)             : controls                                                
flags (f)            : 0x0                                                     
target name (tn)     : c1auxex                                                 
startup script (s)   : /cvs/cds/caltech/target/c1auxex/startup.cmd             
                                                                               
Attaching network interface ei0... done.                                       
Attaching network interface lo0... done.                                       
Loading...                                                                     
Error loading file: errno = 0x320001.                                          
Can't load boot file!! 

 We fixed this problem (at least for now) by adding c1auxex to the /etc/hosts file on chiara (following a hint from this page). The DNS setup might be the culprit here.

  10188   Fri Jul 11 22:02:52 2014 Jamie, ChrisOmnistructureCDScdsutils: multifarious upgrades

To make the latest cdsutils available in the control room, we've done the following:

Upgrade pianosa to Ubuntu 12 (cdsutils depends on python2.7, not found in the previous release)

  • Enable distribution upgrades in the Ubuntu Software Center prefs
  • Check for updates in the Update Manager and click the big "Upgrade" button

Note that rossa remains on Ubuntu 10 for now.

Upgrade cdsutils to r260

  • Instructions here
  • cdsutils-238 was left as the default pointed to by the cdsutils symlink, for rossa's sake

Built and installed the nds2-client (a cdsutils dependency)

  • Checked out the source tree from svn into /ligo/svncommon/nds2
  • Built tags/nds2_client_0_10_5 (install instructions are here; build dependencies were installed by apt-get on chiara)
  • ./configure --prefix=/ligo/apps/ubuntu12/nds2-client-0.10.5; make; make install
  • In /ligo/apps/ubuntu12: ln -s nds2-client-0.10.5 nds2-client

nds2-client was apparently installed locally as a deb in the past, but the version in lscsoft seems broken currently (unknown symbols?). We should revisit this.

Built and installed pyepics (a cdsutils dependency)

  • Download link to ~/src on chiara
  • python setup.py build; python setup.py install --prefix=/ligo/apps/ubuntu12/pyepics-3.2.3
  • In /ligo/apps/ubuntu12: ln -s pyepics-3.2.3 pyepics

pyepics was also installed as deb before; should revisit when Jamie gets back.

Added the gqrx ppa and installed gnuradio (dependency of the waterfall plotter)

Added a test in /ligo/apps/ligoapps-user-env.sh to load the new cdsutils only on Ubuntu 12.

The end result:

controls@chiara|~ > z
usage: cdsutils  

Advanced LIGO Control Room Utilites

Available commands:

  read         read EPICS channel value
  write        write EPICS channel value
  switch       switch buttons in standard LIGO filter module
  avg          average one or more NDS channels for a specified amount of seconds
  servo        servos channel with a simple integrator (pole at zero)
  trigservo    servos channel with a simple integrator (pole at zero)
  audio        Play channel as audio stream.
  dv           Plot time series of channels from NDS.
  water        Live waterfall plotter for LIGO data

  version      print version info and exit
  help         this help

Add '-h' after individual commands for command help.
 
 
  10187   Fri Jul 11 20:05:34 2014 JenneUpdateLSCQPD dark noise checkout

The other day, I took spectra of the Yend transmission QPD dark noise for several different configurations of the transimpedance gain and the whitening gains. 

I also calculated with Optickle the expected sensitivity vs. CARM offset for the sqrtInv CARM sensor. 

I put these things together to get a plot of transmission QPD noise vs. CARM offset, for a chosen set of analog settings.


Measurement of Yend transmission QPD dark noise

Since EricQ had already checked out the whitening filters (see elog 9637 and elog 9642), I didn't check on them.  I just left them (the analog whitening, and the digital antiwhitening filters) on. 

First, I checked the noise vs. transimpedance gain. There are a few too many settings to put them all on one plot, so I have them sorted by the original transimpedance:  0.5 kOhms vs 5 kOhms.  It's a little tricky to see, but all of the spectra that begin with the 5k transimpedance have a little extra noise around 10 Hz, although I don't know why.  In the legend I have made note of what the settings were.  x1 x1 is my representation of the "inactive" setting.

TransQPDY_darkNoise_vs_TransimpedanceGain_9July2014.pdf

I then looked at the noise with different whitening gain slider settings.  All but one of the traces are the 20 kOhm setting.  

TransQPDY_darkNoise_vs_WhiteningGain_9July2014.pdf

These .xml files are in /users/jenne/Arms/TransQPDnoise_July2014/


Calculation of inverse sqrt transmission sensitivity

I used Optickle to give me the power transmitted through the ETMs.  I first find the transmission in the FPMI case.  I use that to normalize the full PRFPMI transmission, so that the output units are the same as our C1:LSC-TR[x,y]_OUT units. 

I take the square root of the transmitted power (sum of transmissions from each arm) at each CARM offset point, add 1e-3 as we do in the front end model to prevent divide-by-zero problems, and then take the inverse.

I find the slope by taking the difference in power between adjacent points, divided by the CARM offset difference between those points. 

In this plot, I have taken the absolute value of the sensitivity, just for kicks.  I also display an arbitrarily scaled version of the log of the transmitted power, so that we can see that the highest sensitivity is at half the maximum power.

sqrtTrans_sensitivity.png


 Calculate the QPD dark noise in terms of meters

Finally, I put it all together, and find the dark noise of the QPD in terms of meters.  Since the spectra were measured in units where the single-arm transmission is unity, the already match the units that I used to calculate the sqrtInv sensitivity. 

I take the spectra of the QPD dark noise for the 20 kOhm case, and multiply it by the sensitivity calibration number at several different CARM offsets.  As we expect, the noise is the best at half-max transmission, where the sensitivity is maximal. 

sqrtTrans_Noise_vs_CARMoffset.png

  10186   Fri Jul 11 17:49:12 2014 NichinUpdateElectronicsNew Prologix GPIB-Ethernet controller

I have configured a NEW Prologix GPIB-Ethernet controller to use with HP8591E Spectrum analyzer that sits right next to the control room computers.

Static IP: 192.168.113.109

Mask: 255.255.255.0

Gateway: 192.168.113.2

I have no clue how to give it a name like "something.martian" and to update the martian host table (Somebody please help!!)

 

  10185   Fri Jul 11 15:29:26 2014 HarryUpdateGeneralTelescope With Collimator

 I used a la mode to make a design for the coupling telescope with a 3.3um target waist, that included the collimator in the overall design. The plot is below, and code is attached.

The components are as follows:

 label         z (m)     type    parameters         

   -----         -----     ----    ----------         

    lens1         0.7681    lens    focalLength: 0.5000

    lens2         0.8588    lens    focalLength: 0.0350

    collimator    0.8832    lens    focalLength: 0.0020

 

The z coordinates are as measured from the beam waist of the NPRO (the figure on the far left  of the plot).

Moving forward, this setup will be used to couple the NPRO (more specifically, the AUX lasers) light into the SM 980 fibers, as well as to help characterize the fibers themselves.

Ultimately, this will be a key component in the Frequency Offset Locking project that Akhil and I are working on, as it will transport the AUX light to the PSL, where the two beams will be beaten with each other to generate the input signal to the PID control loop, which will actuate the temperature servos of the AUX lasers.

Attachment 1: telescope_2.zip
Attachment 2: telescopeWCollimator.png
telescopeWCollimator.png
  10183   Fri Jul 11 11:51:03 2014 NichinUpdateElectronicsPDFR: List of DC transimpedances

The following values are going to be entered in the param_[PDname].yml file for each PD. I am elogging them for future reference.

I got the values from combing schematics and old Elog entries. Please let me know if you believe the values are different.

  • AS55: 66.2 ohms
  • REFL11 : 66.2 ohms 
  • REFL33 : 50.2 ohms
  • REFL55: 50 ohms (Elog 4605)
  • REFL165: 50.2 ohms
  • POY11: 66.2 ohms
  • POX11: 50.2 ohms
  • REF (NF1611): 700 ohms
  • POP22: ?? (This is currently a Thorlab BBPD )
  10182   Fri Jul 11 09:41:43 2014 not KojiUpdateGeneralCoupling telescope design

Quote:

CFC-2X-C has a FIXED focal length of 2mm, but the collimator lens position is adjustable.
I'm not yet sure this affects your calculation or not as what you need is an approximate mode calculation;
once you couple the any amount of the beam into the fiber, you can actually measure it at the output of the fiber with a collimator attached.

 I don't believe it had any effect, as all the calculations gave me the same target waist.

  10181   Fri Jul 11 08:11:56 2014 SteveUpdateCDSETMX needs help
Attachment 1: ETMX.png
ETMX.png
  10180   Thu Jul 10 19:37:54 2014 ManasaUpdateGeneralPM980 fiber tested OK

[Harry, Manasa]

This is the update from yesterday that Harry missed to elog.

We pulled out the first spool of the PM980 fiber yesterday and checked it using the illuminator at the SP table. Harry will be using this for all his tests and characterisation of the fiber.

  10179   Thu Jul 10 18:25:18 2014 KojiUpdateGeneralCoupling telescope design

CFC-2X-C has a FIXED focal length of 2mm, but the collimator lens position is adjustable.
I'm not yet sure this affects your calculation or not as what you need is an approximate mode calculation;
once you couple the any amount of the beam into the fiber, you can actually measure it at the output of the fiber with a collimator attached.

  10178   Thu Jul 10 17:53:19 2014 AkhilConfigurationComputer Scripts / ProgramsEPICS installed on Raspberry Pi

 I finished the installation of EPICS base on Raspberry Pi (domenica:  /opt/epics). I tested it by creating a test SoftIoc (controls@domenica~/freqCountIOC/simple.db) and was able to read from the channel on Chiara.

Now  I am looking into how to call my C code that talks to Raspberry Pi through a  .db script and write  it into the assigned channel. 

For installation I had to make these declarations in the environment (~/.bash_aliases):

 

 

 

export EPICS_EXT=${EPICS_ROOT}/extensions
export EPICS_EXT_BIN=${EPICS_EXT}/bin/${EPICS_HOST_ARCH}
export EPICS_EXT_LIB=${EPICS_EXT}/lib/${EPICS_HOST_ARCH}
if [ "" = "${LD_LIBRARY_PATH}" ]; then
    export LD_LIBRARY_PATH=${EPICS_EXT_LIB}
else
    export LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:${EPICS_BASE_LIB}
fi
export PATH=${PATH}:${EPICS_EXT_BIN}

 

  10177   Thu Jul 10 17:33:26 2014 jamieOmnistructureComputer Scripts / Programsubuntu12 software installed, gds 2.16.3.2

Rana wanted the latest GDS installed (for newest DTT), so I made an ubuntu 12 install directory into which I installed

  • gds-2.16.3.2
  • root_v5.34.03

I installed this stuff in

/ligo/apps/ubuntu12

which is the "official" location for stuff compiled specifically for ubuntu12.

Given that the workstations are diverging in OS (some ubuntu10, some ubuntu12), we're going to have to start supporting different software packages for the different versions, thus the new ubuntu12 directory.  This will be a pain in the butt, and will certainly lead to different versions of things for different machines, different features, etc.  We should really try to keep things at the same OS.

In any event, if you want to enable the GDS on an ubuntu 12 machine, source the ubuntu12 ligoapps-user-env.sh file:

controls@ottavia|~ > . /ligo/apps/ubuntu12/ligoapps-user-env.sh

  10176   Thu Jul 10 15:57:00 2014 SteveUpdateSUSflow bench is turned off

Flow bench effect on oplev error signal     is here.

I turned off the south X-end flow bench.

  10175   Thu Jul 10 15:27:09 2014 HarryUpdateGeneralCoupling telescope design

 I designed this telescope to couple the 1064 NPRO into the PM980 fiber, using lenses from the Thorlabs LSB04-C kit.

The collimator is a CFC-2X-C, which has a variable focus length (2.0, 4.6, 7.5, and 11.0 mm) which gives corresponding angles of divergence of 0.298, 0.130, 0.79, and 0.054 degrees by the formula theta = (180*MFD) / (pi*f).

Then, using these values I calculated the spot size of a beam collimated by the CFC-2X-C, using f = w / tan(theta) where w is the spot size. This gave a value of 10.4 um.

I used this value (10.4 um) as a target waist for the telescope system, with the NPRO waist as a seed, at the origin.

telescopeBeamProfile.png

It consists of two lenses, one located at Z = 77cm f = 50cm, and the second located at Z = 85.88 cm f = 2.54cm, which yields a waist of 13um at Z = 88.32cm, (which is where the collimator would go) for an overlap of .974.

Note that the telescope is so far "downrange" from the NPRO waist because it's a virtual waist, and the NPRO itself is located at about Z = 73cm.

Find attached the alm code used.

Attachment 2: telescope.zip
  10174   Thu Jul 10 02:15:36 2014 JenneUpdateLSCQPD dark noise checkout

I have put beam dumps in front of both of the end transmission QPDs so that I could measure the dark noise.  They are still there.

I checked that the Yend QPD sliders and switches were doing things as I expected.  I couldn't do the Xend since c1auxex is still lost (elog 10165).  I'll post plots and actual information on this checkout, as well as my calculation of what this dark noise means in terms of meters for CARM when we're using 1/sqrt(trans) signals tomorrow morning. 

  10173   Thu Jul 10 02:09:20 2014 JenneUpdatePSLFSS Fast gain set

I have put in a new nominal value for the FSS fast gain:  21.5 dB. 

There is an oscillation peak in the MC error point spectra around 41.5 kHz if the FSS gain is set too high.  I used the 4395 to have a look at the MC error point, and saw that if I set the FSS fast gain any lower than about 18 dB, the peak wasn't getting any smaller than -41 dBm.  If I set the fast gain any higher than about 26 dB the peak wouldn't get any larger than about -34 dBm. 

However, if I set the gain to 19.5dB, the PC RMS drive is consistently above 2 V, which isn't so good.  If I crank the gain up to 27 dB or more, the PC RMS will stay below 0.9 V, which is great. 

As a compromise, I have decided on 21.5 dB as the new FSS fast gain.  This puts the oscillation peak at about -39.5 dBm, and the PC RMS around 1.6 V.

I changed the nominal gain by ezcawrite C1:PSL-STAT_FSS_NOM_F_GAIN 21.5.  This sets the nominal value so that the FSS screen's fast slider doesn't turn red at the new value.  And, since the MC autolocker reads this epics channel and puts that into the gain during the mcup script, the MC autolocker now uses this new gain.  For reference, it used to be set to 23.5 dB.

  10172   Thu Jul 10 01:02:13 2014 ranaUpdatePSLmore PMC science

Increased gain and SNR in PMC LO monitor circuit.

  1. R20: 499 -> 50k Ohms (increases gain by 100)
  2. Used Marconi to drive the LO input and readout C1:PSL-PMC_LODET
  3. Fit this function and loaded it into the psl.db file. The old Kalmus way used LOGE, but I wanted to use log10, so I did. The sensor is only useful in a narrow band. Since the signal is so low at low levels, I just fit to the highest 4 points because I was too lazy to do proper weighting. Do as I say, not as I do.

Plot with data and fit attached.

** N.B.: in order to update the calibration without rebooting, I used the following command: z write C1:PSL-PMC_LOCALC.CALC "2.235*LOG(B)+12.265". This allows us to update EPICS CALC records without rebooting the IOC.

Attachment 1: PMCloCal.pdf
PMCloCal.pdf
  10171   Thu Jul 10 00:38:20 2014 manasaUpdateGeneralAOM and PSL Ringdown

Quote:

RXA: some more comments...

  1. The fact that the AOM can only modulate the power by a tiny bit means that it is very mis-aligned or that the driver is broken.
  2. You need to take into account the AOM step time in the calculation of the PMC step time. Its not a step response if the input step is not a step, but a exponential.
  3. I wouldn't trust that old John Miller entry for the PMC Finesse. As you can see from his elog, even he didn't trust it.
  4. As we were discussing before, making a little step is not the same as a full ringdown. cf. G000413 and T900007

 

I think we should revisit the AOM alignment because the last time it was aligned, PMC trans dropped from 0.84 to 0.15 (a little more than 80%) for 0-1V modulation input to the AOM driver [elog]. The drop in power right now is ~10-15% only.

I could not find any elogs of AOM alignment touchups after Oct 2012.
But can the ISS team throw some light on the status of AOM when they were installing the ISS servo before we decide on touching the AOM alignment? [elog

  10170   Wed Jul 9 23:02:33 2014 HarryUpdateGeneralBeam Waists via Beamscan

 Today, I borrowed the beam profiler from Brian (another SURF) in order to double check my razor blade measurement figures, using the below setup:

beamscanSetup.png

Measurements are included in the a la mode code that is attached entitled beamfit.m. The beam fitting application yielded me waists (after the lens) of 35.44 um in the x plane, and 33.26 um in the y plane. These are both within 3 um of the measurements I found using the razor blade method. (I moved and resized the labels for the waists in the figure below for readability purposes.)

beamScanWaists.png

I then plugged these waists back into ALM, in addition to the lens specifications, to determine waist size and location of the NPRO, which turned out to be 543 um in the x located at Z = 1.160m, and 536 um in the y, located at 1.268m. These measurements are based upon zero at the waist after the lens, and the positive direction being back toward the NPRO.

beamProfileX.pngbeamProfileY.png

The only systemic difference between these measurement and my original razor blade measurements was that I had taken the focal length of the lens as 75mm, which is advertised on the manufacturer's site. However, the more detailed specs revealed that the focal length was 85.8mm at 1064nm, which made a difference of about 400 um for the final waist determination.

Attachment 4: beamScanWaist.zip
  10169   Wed Jul 9 21:43:41 2014 JenneUpdateElectronicsPMC servo card modifications in DCC

[Rana, Jenne]

We have decided to keep better track (using new-fangled digital "computers") of our modifications to electronics boards. 

The idea will be to create a new DCC document for every electronics board (when we pull a board and modify it, it should receive this treatment) that we have, and that document will become a history of the board's life.  Version 1 will be a copy of the original drawing.  Version 2 should be a modified version of that drawing with the current situation.  All future versions should be modified from the most recent version, to reflect any changes.  Notes for each updated version should include an elog reference to the work, so that we know why we did things, and have a place to find photos of the actual modifications.  Elogs should also include a link to the DCC version.  DCC titles should include the phrase "40m Revisions" for ease of searching.

Patient Zero for this new system will be the PMC servo card.  The DCC number is D1400221.  As of this moment, this just has the V1 original drawing with no modifications.

This has been included in the 40m's DCC document tree that Jamie started back in November 2012.

  10168   Wed Jul 9 21:05:31 2014 manasaUpdateGeneralAOM and PSL Ringdown

After the fits, here are the numbers!

Component Measured Expected
AOM 85.1 ns 200 ns (spec sheet) 
PMC 164.6 ns  Finesse/(2*pi*FSR)  = 163.4 ns

* We have a huge difference to the AOM switching time that was measured. The spec sheet mentions acoustic velocity in the material to be 4.2 mm/us and the well matched diameter in the AOM to be 1100 um. This would give a switching time ~ 200 ns. We could probably be having a much smaller beam size in the AOM for the measured switching time.

* The PMC  parameters that I had been referring to from the wiki were actually wrong and which was the reason for the mismatch that I was finding. I modified the wiki according to the found references to the actual measurement here: PMC parameters The measured values now and then match pretty well.

* Since the AOM does not change the power of the output beam by very much, what we see is actually a step response. Also, we have a lot of noise in the data obtained at the PD. 

RXA: some more comments...

  1. The fact that the AOM can only modulate the power by a tiny bit means that it is very mis-aligned or that the driver is broken.
  2. You need to take into account the AOM step time in the calculation of the PMC step time. Its not a step response if the input step is not a step, but a exponential.
  3. I wouldn't trust that old John Miller entry for the PMC Finesse. As you can see from his elog, even he didn't trust it.
  4. As we were discussing before, making a little step is not the same as a full ringdown. cf. G000413 and T900007

 

Attachment 1: data_code.zip
Attachment 2: PSL_ringFit.pdf
PSL_ringFit.pdf
Attachment 3: AOMringFit.pdf
AOMringFit.pdf
  10167   Wed Jul 9 19:53:34 2014 ranaUpdatePSLPMC LO monitor trend (5 years)

LODET.png

The first step is

The second uptick (In Nov 14, 2013) is when I removed a 3 dB attenuator from the LO line. Don't know why the decay accelerates after that.

  10166   Wed Jul 9 17:34:11 2014 NichinUpdateElectronicsPDFR: Beam pointing adjustments and DC measurements

 [Nichin, Manasa]

AIM: Taking DC output readings with multimeter for each PD to create a database (required for transimpedance calculations), by taking off the table tops. Also, making sure each PD is illuminated properly.

What we did:

  • In rack 1Y1: Diode laser controller was set to 150.0 mA at all times. This gave powers in the neighbourhood of 1mW at the end of fibers illuminating all PDs. The laser outputs light of 1064nm wavelength. The laser was switched off in the end.
  • Checked the collimation of the fiber for each PD. In some cases they were not focused to give a sharp spot, so we had to unmount the fibers and fix it and mount them back. Manasa did it initially and I learnt how it was done properly. Eventually I got better and did it myself (under her supervision)
  • Set the mount alignment for maximum illumination of the PD.
  • Record the power falling on the laser and also the DC voltage output. Any light that did not come from my fiber was blocked when taking the readings and then unblocked. I also took care of offset voltage present when taking the DC readings.

Recorded measurements:

REFL11:   Pinc = 0.91 mW         VDC = 34.9 mV 

REFL33:   Pinc = 0.83 mW         VDC = 33.2 mV 

REFL55:   Pinc = 1.08 mW         VDC = 42.7 mV 

REFL165: Pinc = 0.79 mW         VDC = 115.3 mV

AS55:         Pinc = 0.78 mW         VDC = 31.3 mV

POX11:      Pinc = 0.83 mW         VDC = 34.7 mV

POP22**:   Pinc = 1.08 mW         VDC = 5.82 mV

POY11:      Not illuminated; there was no optical fiber mount. Although, there was a fiber near it with a cap on the end. It also looks like there is no space to put in a new mount near the PD. 

REF PD:    Pinc = 1.19 mW         VDC = 8.2 V     (REF PD = New focus 1611)

**Note: The current POP 22 PD does not have 2 different outputs for DC and RF signals. I unplugged the RF cable from the output, took readings with the multimeter and then plugged back the RF cable.

Further work:

I will calculate the responsivity for each PD and compare it to the expected values. 

  10165   Wed Jul 9 17:08:29 2014 JenneUpdateCDSc1auxex "Unknown Host"

c1auxex has forgotten who it is.  Slow sliders for the QPD head were not responding, so I did a soft reboot from telnet. The machine didn't come back, so I plugged the RJ45-DB9 cable into the machine and looked at it through a minicom session.  When I key the crate, it gives me an error that it can't load a file, with the error code 0x320001.  Looking that up on a List of VxWorks error codes, I see that it is:    S_hostLib_UNKNOWN_HOST (3276801 or 0x320001)

I'm not sure how this happened.  I unplugged and replugged in the ethernet cable on the computer, but that didn't help.  Rana is going in to wiggle the other end of the ethernet cable, in case that's the problem.  EDIT:  Replacing the ethernet cable did not help.

Former elogs that are useful:  10025, 10015

EDIT:  The actual error message is:

boot device          : ei                                                      
processor number     : 0                                                       
host name            : chiara                                                  
file name            : /cvs/cds/vw/mv162-262-16M/vxWorks                       
inet on ethernet (e) : 192.168.113.59:ffffff00                                 
host inet (h)        : 192.168.113.104                                         
user (u)             : controls                                                
flags (f)            : 0x0                                                     
target name (tn)     : c1auxex                                                 
startup script (s)   : /cvs/cds/caltech/target/c1auxex/startup.cmd             
                                                                               
Attaching network interface ei0... done.                                       
Attaching network interface lo0... done.                                       
Loading...                                                                     
Error loading file: errno = 0x320001.                                          
Can't load boot file!! 

  10164   Wed Jul 9 16:33:05 2014 manasaUpdatePSLPMC ringdown setup

Quote:

Quote:

I moved stuff on the PSL table to accommodate the PMC ringdown setup.

I used the beam that leaks from the steering mirror at the PMC transmission that was dumped to a razor blade dump. I installed a Y1 to steer the beam to the ringdown PD. Power in the beam 75mW. 

 I am guessing that 75 mW will burn / destroy any Thorlabs PD. I hope that mW is supposed to be uW.

 It was ~7.5mW and measured ~2V at the PD output (given its range 0-5V ) on the oscilloscope . So PD is safe !

  10163   Wed Jul 9 12:01:43 2014 AkhilConfigurationElectronicsSetup Plan for placing the Frequency Counter inside the lab

Today, me and Manasa went inside the lab to figure out a place for the place for the FC. The whole setup will be placed in a chassis box . The chassis in figure(setupforFC.pdf) will be placed in the highlighted(red) box in the figure(setup.png). All the cables will be routed to the computers from behind the box and the RF cables from the beat box will be routed from the front end of the box. The two raspberry Pi boxes will be placed inside the box and the Frequency counters will be mounted as shown so that the frequency count can be seen from outside. 

Attachment 1: setup.png
setup.png
Attachment 2: SetupFC.png
SetupFC.png
ELOG V3.1.3-