Over the weekend and today, the wifi was acting bad with frequent disconnections and no internet access. I tried to log into the web interface of the ASUS wifi but with no success.

I pushed the reset button for several seconds to restore factory settings. After that, I was able to log in. I did the automatic setup and defined the wifi passwords to be what they used to be.

Internet access was restored. I also unplugged and plugged back all the wifi extenders in the lab and moved the extender from the vertex inner wall to the outer wall of the lab close to the 1X3.

Now, there seems to be wifi reception both in X and Y arms (according to my android phone).

Ug, factory resets... Caltech IMSS announced that there was an intermittent network service due to maintenance between Sept 19 and 20. And there seemed some aftermath of it. Check out "Caltech IMSS"

I've added a new page in the wiki which describes the current naming scheme for the .mdl model files used for the real time code generator.  Note, that these model names do not necessarily have to be the names of the channels contained within.  Its still possible to make all suspension related channels start with C1:SUS- for example.  I'm also allocating 1024 8 byte channels for shared memory address space for each controller and each simulated plant.

The wiki page is here

Name suggestions, other front end models that are needed long term (HEPI is listed for example, even though we don't have it here, since in the long run we'd like to port the simulated plant work to the sites) are all welcome.

I've set up the Wilcoxon accelerometers on the SP table for a huddle test, to estimate their noise levels. 

They're clamped down to the table along the same axis, and their housings are in good contact, in hopes to make them as correlated as possible. 

Steve helped me move the DAQ cables from under the BS/PRM oplev table, to dropping from the cable tray above the POX table, so I could get them plugged in at the SP table. This also helps reduce the rats nest by the access connector, and is a fine location for when the accelerometers are attached at MC1 & MC2. 

A quick glance at DTT shows coherence of >0.9 from about 2-100Hz for all six. A three-corner-hat deal will provide an easy estimate of the noise floor of each one. If we feel like being fancy / accounting for possible gain differences, we could try some MISO wiener action, but that is probably overkill. 

Here are some results for the 3-corner hat subtraction for the six accelerometers, from ~1 hour of data that didn't look to have any sharp features/glitches from human activity in the lab. 

I used the python uncertainties package to try and get an estimate of the uncertainty in the subtracted noise floor, by taking into account every possible possible combination of 3 sensors and the fluctuations in the spectrograms of the subtracted signals. I've attached the python code if anyone is interested in the implementation. 

I pulled out the accelerometer data sheets to read their slightly varying V/g calibration (which differs on the order of a few percent from unit to unit). This improved the subtraction factor from ~20 to over 100 at some frequencies. I've edited the filter modules such that the OUT_DQ channels are already calibrated into m/s^2.

To improve our sensor noise estimate, the ACC cables should be clamped using a rubber pad and a big dog clamp on the SP tabletop before exiting the table. Also the sensors themselves should be covered with a foam box or a double cardboard box. The high-frequency acoustic noise may limit the 10 Hz performance since piezos are not very linear.

Wilcoxon. Not Wilconox or Wilco or Wilcoxen. Have some pity on future keyword searchers.

Updated: On Thursday/Friday (sorry for late elog) I was messing with Eric's Wilcoxon 731A accelerometer huddle test data that was taken without the box and cables being adjusted properly. Anyways, I performed the three cornered hat analysis as he had done but I also performed a six cornered hat method as well instead of permuting around in pairs of three accelerometers. The following plots of the ASD's show the results,

It is interesting to note the improvement at low frequencies when six accelerometers are used instead of six while at higher frequencies we can clearly see how the results are worst than the three hat results.

I decided to take a mean of all six accelerometers measured ground signal as well as that for their computed selfnoises, this is plotted below,

Notice the obvious improvement along the entire frequency band of the measurements when all accelerometers are used in the data analysis.

I also performed some Wiener filtering of this data. There was an obvious improvement in the results,

The mean of the signals is also plotted below, just as I did with the cornered hat methods,

I also compared the mean self noise of the accelerometers against the manufacturers calculated selfnoise that Rana put up on Github. Both methods are compared against what the manufacturer claims,

As expected the measured noise curves of the Wilcoxon is not as good as what the manufactures stated. This should improve once we redo the huddle test with a better experimental setup. We have some pretty interesting results with the six cornered hat method at around 5 Hz, it is surprisingly accurate given how rough the calculations seemed to be.

I have attached my code for reference: code_accel.zipselfnoise_allsix.png

SEE attachments for better plots of the six accelerometers...

Eric and Steve,

 We removed Wilcoxon Accelerometer PS and Amplifier unit under the BS optical tabel yesterday. The six cabels going to DAQ  were labeled and left in place. Gain setting were 100, except channel 3 was 10.

The ~ 40 m long 2 sets of 3 cables were very happy to get their kinks out. Especially the set going just south of ITMX optical  table.

We have to take better care of these cables! Your data will be useless this way.

[Kiwamu, Jenne, Alberto, Steve, Bob, Koji]

We finished wiping of four test masses without any trouble. ITMY looked little bit dusty, but not as much as ITMX did.
We confirmed the surface of the ITMX again as we worked at vertex a lot today. It still looked clean.

We closed the light doors. The suspensions are left free tonight in order to check their behavior.
Tomorrow morning from 9AM, we will replace the door to the heavy ones.

When Alberto was parting the Red Sea this morning, and turning it green, he noticed that the wireless had gone sketchy.

When I checked it out, the ethernet light was definitely blinking, indicating that it was getting signal.  So this was not the usual case of bad cable/connector which is a known problem for our wireless (one of these days we should probably relay that ethernet cable....but not today).  After power cycling and replugging the ethernet cable, the light for the 2.4GHz wireless was blinking, but the 5GHz wasn't.  Since the wireless still wasn't working, I checked the advanced configuration settings, as described by Yoichi's wiki page:  40m Network Page

The settings had the 5GHz disabled, while Yoichi's screenshots of his settings showed it enabled.  Immediately after enabling the 5GHz, I was able to use the laptop at Alberto's length measurement setup to get online.  I don't know how the 5GHz got disabled, unless that happened during the power cycle (which I doubt, since no other settings were lost), but it's all better now.

After poking around for a few minutes several facts became clear:

1) At least one GPIB interface has a hard ethernet connection (and does not currently go through the wireless).

2) The wireless on the laptop works fine, since it can connect to the router.

3) The rest of the martian network cannot talk to the router.

This led to me replugging the ethernet cord back into the wireless router, which at some point in the past had been unplugged.  The computers now seem to be happy and can talk to each other.

I installed a NETGEAR Wireless Router (WPN824N) today on the 131 network. The admin password for it as well as the wireless access password are in the usual places.

The SSID is 40EARTH. I have set it to allow WPA as well as WPA2 access, so the speed is only 54 Mbps for now. In a year or so, we can turn off the WPA support and up the speed.

 This router was confiscated by the GC guys this morning around ~10am.  They barged in and said that someone at the 40m had connected a new router, and we had magically taken down half of the GC network.  The cable was plugged in to the wrong port on the back of the router. 

Junaid / Christian said that they would "secure" the router, and then reinstall it.  Apparently just having a password didn't satisfy them.  This was the compromise, versus them just taking the router and never bringing it back.

I retrieved the newly "secured" router from Junaid.  It had apparently been hooked up to the GC network via it's LAN port, but it's LAN services had no been shut off.  It was therefore offering a competing DHCP server, which will totally hose a network.  A definite NONO.

The new SSID is "40mWiFi", it's WPA2, and the password is pasted to the bottom of the unit (the unit is back in it's original spot on the office computer rack.

I've attached a schematic for how we will connect the Acromag mosules to the slow channel I/O curently going to c1auxex. The following changes are made:

• We are getting rid of the slow readbacks from the Anti-Image and Oplev boards, as Rana says they are unnnecessary.
• The whitening switching for the QPD is currently done by a Contec "fast" binary I/O module, but can be managed by acromag instead. This alllows CAB_1Y9_34 to  be fed directly into the Acromag box since all of its connections can now be managed slow. 
• There's no need to change the PD whitening scheme around (since the signals never get huge), so we can set those to always be on and then lose those Contec channels. This means all of the necessary pins on CAB_1Y9_10 can go to Acromag. 
• All the other backplane cables go the the fast machines only. 

Wiring of the power, Ethernet, and indicator lights for the vacuum Acromag chassis is complete. Even though this crate will only use +24V DC, I wired the +/-15V connector and indicator lights as well to conform to the LIGO standard. There was no wiring diagram available, so I had to reverse-engineer the wiring from the partially complete c1susaux crate. Attached is a diagram for future use. The crate is ready to begin software developing on Monday. 

Here is my work plan for this week:

Current Week Plan (Week 2) (As of 6/17/11)

Setting Up for Horizontal Displacement Measurements

Begin Assembly of Sensors

A rough time-table and the various tasks are given below:

Note:  700mW NPRO sitting on AP table (Model No: 126-1064-700, Sl No. 415)  = Alberto's laser

Razib and I were attempting to get the output of a photodiode (PD55A in this case) recorded, so that we could independently measure the slow (~1-10 Hz) fluctuations of the light incident on the camera.  This would then allow us to subtract those fluctuations out, letting us get at the camera noise in the case with signal present (as opposed to just a dark noise measurement when we look at the noise with no signal present).

Originally I was thinking of using one empty patch panel BNCs used for PEM channels down by the 1Y7 rack and go through a 110B, although Alberto pointed out he had recently removed some monitoring equipment, which watched the amplitude modulation at various frequencies of the RF distribution (i.e. 33 MHz, etc).  This equipment output a DC voltage proportional to the amplitude of the RF signals.  The associated channel names were C1:IOO-RFAMPD_33MHZ, C1:IOO-RFAMPD_33MHZ_CAL, C1:IOO-RFAMPD_133MHZ, etc.  These are slow channels, so I presume they enter in via the slow computers, probably via pentek (I didn't check that, although in hindsight I probably should have taken the time to find exactly where they enter the system).  The connections them selves were a set of BNCs on the south side, half way up the 1Y2 rack.

We simply chose one, the 33 MHz channel in this case, and connected.  At around this time, the MC did become unlocked, although it looked like it was due to the MC2 watchdog tripping.  The initial theory was we had bumped the Mode Cleaner while looking around for some BNC cables, although from what Rana had to do last night, it probably was the connection.  We were able to restore the watchdog and confirm that the optic started to settle down again.  Unfortunately, I had to leave about 5 minutes later, and didn't do as thorough an investigation as was warranted.

 Before I left, I disconnected the PD55, so the 33 MHz channel wasn't physically connected to anything!!! Only one end of the wire was connected to the rack while the other was free...

So it wasn't the PD connection that is responsible for MC tripping at the later time...

Now that the .db files were prepared, I wanted to test for errors. So I did the following:

1. Acromags were mounted on the DIN rails. Attachment #1 shows the grouping of ADC, DAC and BIO units. They are labelled with their IP addresses.
2. Wiring of power:
   • Chub had already prepared the backplane with the power connectors, switches and indicator LEDs.
   • So I just had to daisy chain the +24 V (RED) and GND (BLACK) terminals for all the acromags together, which I did using 24 AWG wire (we may want to use heavier gauge given the current draw).
3. Ethernet cables were used to daisy chain the network connectivity between the various units.  Attachment #1 shows the current state of the chassis box.
4. Front panel pieces were attached and labelled, see Attachment #2. 
   • I found it was sufficient to use the front - we may use the rear panel slots when we want to add connections for controlling the c1aux machine channels.
   • The D15 P2 connector panel for the CM board will arrive tomorrow and will be installed then.
5. Entire setup was connected to power and ethernet, see Attachment #3. 
   • As usual, the current draw is significant for the collection of Acromags, I got around this problem by using the bench supply to "Parallel" mode to enhance the current driving capacity.
   • For the ethernet connection, I used the office space port #6, which I connected at the network rack end to the eth1 port of the Supermicro.

All the Acromags are seen on the 192.168.114 subnet on c1iscaux3 - however, when I run the modbusIOC process, I see various errors in the logfile , so more debugging is required. Nevertheless, progress.

Update 2245: Turns out the errors were indeed due to a copy/paste error - I had changed the IP addresses for the ADCs from the .115 subnet c1susaux was using, but forgot to do so for the DACs and BIOs. Now, if I turn off the existing c1iscaux so that there aren't any EPICS clashes, the EPICS server initializes correctly. There are still some errors in the log file - these pertain to (i) the mbbo notation, which I have to figure out, and (ii) the fact that this version of EPICS, 7.0.1, does not support channel descriptions longer than 28 characters (we have several that exceed this threshold). I think the latter isn't a serious problem.

Getting closer... Note that I turned off the c1iscaux VME crate to prevent any EPICS server clashes. I will turn it back on tomorrow.

• Recenter the beam on the 2 lenses that are just after the PBS and the waveplate
  
• Adjust pitch and yaw of the two steering mirrors until the beam reflected off the input mirror of the reference cavity is parallel to the incident beam
  
  • Use a sensor card to check the alignment of the incident and reflected beams, and adjust the steering mirrors to get the alignment close
    
    • Note the amplitude of the DC output of the Refl. PD with the iris completely open. Close the iris until the signal decreases by ~50%, then adjust the steering mirrors until the original amplitude is regained. Repeat until the iris can be almost completely closed but the Refl. PD signal doesn't change
      
  • Watch the DC output of the Refl. PD, and maximize the signal on a 'scope
    
  • Sweep the PZT of the laser using a function generator into the RAMP input on the FSS board (~10Vpp at ~1Hz), OR sweep the temperature of the laser using the trianglewave function on the SLOW FSS channel (amplitude~0.5, period~50)
    
  • Watch the modes that resonate in the cavity, and adjust pitch and yaw of the steering mirrors to get closer to the TEM00 mode
    
  • When the TEM00 mode appears in the sweep, stop the sweep, and lock the cavity
    
  • Watch the DC output of the Transmitted PD, and maximize the signal on a 'scope
    
• Celebrate!
  

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.

 [Akhil, Harry]

Work Completed :

 Frequency Counter:

• Interfacing with the Raspberry Pi

• Characterization of the FC:          

                                   - Transfer Function 

                                   - Quantization Noise Estimation

Temperature Actuator:

• Measurement of the Transfer Function

EPICS and Channel Readout:

•  Creating a new Channel Access Server(SoftIOC)
•   Piping data from FC into created channels.              

Frequency Offset Locking(FOL) Box Design and Plan:

• Planning and selection of place for installation.
• Preparation of the box and routing cables.

Work Plan for Upcoming Weeks:

• Calibration of the Thermal Actuator TF and PID loop design.
• Channel Testing after installation of the FOL box inside the 40m.
• Optics:
  • Measure beam profiles of AUX lasers and PSL.
  • Design coupling telescope, given space constraints at end tables
  • Couple lasers into fibers
  • Connect fibers from lasers to fiber coupled Beam Combiner and Photodiode.
• Testing of FOL loop after installation of the complete system.

[Chris, Tega]

Timing glitch investigation:

• Moved dolphin transmit node from c1sus to c1lsc bcos we suspect that the glitch might be coming from the c1sus machine (earlier c1pem on c1sus was running faster then realtime).
• Installed and started c1oaf to remove the shared memory IPC error to/from c1lsc model
• /opt/DIS/sbin/dis_diag gives two warnings on c1sus2
  • [WARN] IXH Adapter 0 - PCIe slot link speed is only Gen1
  • [WARN] Node 28 not reachable, but is an entry in the dishosts.conf file - c1shimmer is currently off, so this is fine.

DAQ network setup:

• Added the DAQ ethernet MAC address  and fixed IPV4 address for the front-ends to '/etc/dhcp/dhcpd.conf'
• Added the fixed DAQ IPV4 address and port for all the front-ends to '/etc/advligorts/subscriptions.txt' for `cps_recv` service
• Edited '/etc/advligorts/master' by including all the iop and user models '.ini' files in '/opt/rtcds/caltech/c1/chans/daq/' containing channel info and the corresponding tespoint files in '/opt/rtcds/caltech/c1/target/gds/param/'
• Created systemd environment file for each front-end in '/diskless/root/etc/advligorts/' containing the argument for local data concentrator and daq data transmitter (`local_dc_args` and `cps_xmit_args`). We currently have staggered the delay (-D waitValue) times of the front-ends by setting it to the last number in the daq ip address when we were facing timing glitch issues, but should probably set it back to zero to see if it has any effect.

Other:

• Edited /etc/resolv.conf on fb1 and 'diskless/root' to enable name resolution via for example `host c1shimmer` but the file gets overwritten on chiara for some reason

Issues:

1. Frame writing is not working at the moment. It did at some point in the past for a couple of days but stopped working earlier today and we can't quite figure out why. 
2. We can't get data via diaggui or ndscope either. Again, we recall the working in the past too but not sure why it has stopped working now.   
3. The cpu load on c1su2 is too high so we should split into two models
4. We still get the occassional IPC glitch both for shared memory and dolphin, see attachments

See Attachment #1.

• The original ETMY actuation matrix was the naive one so I simply retuned everything by adding the butterfly mode appropriately.
• The cross coupling between the DOFs has not been characterized, but the local damping, Oplev loops, POX/POY locking, simpel Michelson locking, and ASS dither alignemnt all seem to work so I'm thinking this is good enough for now.
• A copy of the ETMYaux.db file was made, and the slow bias voltage was redistributed among the three available face OSEMs - note that the magnet polarity has to be taken into account.
• The series resistance on the slow path was reduced from 430 ohms, 1W to 100 ohms, 3W, to allow DC alignment of the cavity axis to the beam axis.
• Vertex Oplevs were re-centered on their respective QPDs after locking POX/POY and running the ASS dither alignment.
• The AS spot was a little low on the camera - presumably the SR2/SR3 got macroscopically misaligned. I re-centered the beam on the camera on the AS table (by moving the camera, the beam path was not disturbed).

The beam spot on ETMY looks weird (looks almost like a TEM10 mode), but the one on ITMY seems fine, see Attachment #2. Wonder what's going on there, maybe just a focusing problem?

[Koji Gautam]

The variable delay line has been setup for practical use. The hardware and basic software are ready.

The delay time is given by [512-1-mod(C1:LSC-BO_1_0_SET, 512)]*(1/16) ns

Giving 511 (LLLL LLLH HHHH HHHH) to C1:LSC-BO_1_0_SET makes the delayline shortest (+0ns).
Giving 0 (LLLL LLLL LLLL LLLL) to C1:LSC-BO_1_0_SET makes the delayline longest (~32ns).

The SR785 was removed from the rack for our access >> Eric

DO setup

- Three CONTEC DO-32L-PE cards are found in the Yarm digital cabinet. (I brought a card from WB, but will bring it back).
- The card was installed in the C1LSC chassis.

- The models for c1x04 and c1lsc were modified to include the card. Once they are restarted, the card was recognized without problem.
  The frame builder also needed to be restarted (Attachment 1&2). The changes were committed to the repository.

- MEDM screen "CDS_BO_STATUS.adl" has been modified to include the bit monitors for the new DO card. (Attachment 3)

Epics values "C1:LSC-BO_1_0_SET" and "C1:LSC-BO_1_1_SET" are hooked up to the DO block.

Cables

- The DO board has DB37(F). I made a I/F cable with a DB37(M) crimp connector, DB25 breakout board, and a ribbon cable.
  Pin 1 is connected to pin 14 of the DB25 (GND of the delayline circuit).
  Pin 2~10 are connected to pin 1~9 of the DB25 (Switch 1~9 of the delayline circuit)
  Pin 18 is connected to X01 (external = spare) (Attachment 4)
 

- [CONFESSION] A bench +15V power supply was prepared to power the transisters of the DO (Attachment 6). The hot side is connected to X01 (not connected to the DB25),
  and the cold side is connected to pin 14 of the DB25. Once we find this is a useful setup we need to make a dedicated interface unit to convert DB37
  into DB25 (and provide more connectivities).

- A DB25 M-F cable was installed on the cable tray above the LSC racks.

Delay line unit

- The delay line box was mounted on 34H of the LSC analog rack (Attachment 5).

- The side cross connect power supply was not available (to be described later). Therefore we decided to use the same +15V supply as the one for the DO card.

- Checked the functionarity of the local switches using a function generator @30MHz and the front panel switches. The maximum (~32ns) delay was confirmed.
  (Just not enough to have 360 deg shift).

- Now the delay line function was tested with the front panel swicth at "ext". We confirmed that the delay time changes with the number given to C1:LSC-BO_1_0_SET.

What we need further

- Implement delay time slider control (511 = 0ns, 0 = 31.94ns). The delay time is given by
  [512-1-mod(C1:LSC-BO_1_0_SET, 512)]*(1/16) ns

- Some independent RF issues I found. (Next entry)

All the details are in E2000436, and documents linked from there, I think an elog would be much too verbose. In summary, a workable setup consisting of

• 2 DCPDs interfaced with the realtime CDS system. Note that because this circuit is single-ended, while the AA and ADC are differential receiving, there is an overall gain of 0.5. Explicitly, for the 300 ohm DC transimpedance, the conversion is ~350 cts/mW.
• A local oscillator beam delivered via fiber that is mode-matched (roughly) with the IFO AS beam.
• A PZT mounted mirror to control the homodyne phase. The PZT (S320) is an obsolete part and it's hard to find a datasheet for it, but if its specs are comparable to the more modern S330, the full stroke is 10 um, for a max applied voltage of 100 V DC, so 100nm/V. c.f. 200V for 3um full stroke of the Noliac.

was prepared.

Last night, I locked the PRMI with the carrier resonant, and convinced myself that the DCPD null stream was sensing the MICH degree of freedom (while it was locked on AS55_Q) with good SNR below ~60 Hz. Above ~60 Hz, in this configuration, the ADC noise was dominating, but by next week, I'll have a whitening board installed that will solve this particular issue. With the optical gain of MICH in this configuration, the ADC noise level was equivalent to ~500 nrad/rtHz of phase noise above ~60 Hz (plots later).

Now, I can think about how to commission this setup interferometrically.

[josephb, osamu, kiwamu]

We worked over by the 1Y2 rack today, trying to debug why we didn't get any signal to the c1lsc ADC.

We turned off the power to the rack several times while examining cards, including the whitening filter board, AA board, and the REFL 33 demod board.  I will note, I incorrectly turned off power in the 1Y1 rack briefly. 

We noticed a small wire on the whitening filter board on the channel 5 path.  Rana suggested this was to part of a fix for the channels 4 and 5 having too much cross talk.  A trace was cut and this jumper added to fix that particular problem.

We confirmed would could pass signals through each individual channel on the AA and whitening filter boards.  When we put them back in, we did noticed a large offset when the inputs were not terminated.  After terminating all inputs, values at the ADC were reasonable, measuring on from 0 to about -20 counts.  We applied a 1 Hz, 0.1 Vpp signal and confirmed we saw the digital controls respond back with the correct sine wave.

We examined the REFL 33 demod board and confirmed it would work for demodulating 11 MHZ, although without tuning, the I and Q phases will not be exactly 90 degrees apart.

The REFL 33  I and Q outputs have been connected to the whitening board's 1 and 2 inputs, respectively.  Once Kiwamu  adds approriate LO and PD signals to the REFL 33 demod board he should be able to see the resulting I and Q signals digitally on the PD1 I and Q channels.

In an unrelated fix, we examined the suspensions screens, specifically the Dewhitening lights.  Turns out the lights were still looking at SW2 bit 7 instead of SW2 bit 5.  The actual front end models were using the correct bit (21 which corresponds to the 9th filter bank), so this was purely a display issue.  Tomorrow I'll take a look at the binary outputs and see why the analog filters aren't actually changing.

After hardware errors prevented me from using optimus, I switched my generation of summary pages back to the clusters. A day's worth of data is still too much to process using one computer, but I have successfully made summary pages for a timescales of a couple of hours on this site: https://ldas-jobs.ligo.caltech.edu/~praful.vasireddy/

Currently, I'm working on learning the current plot-generation code so that it can eventually be modified to include an interactive component (e.g., hovering over a point on a timeseries would display the GPS time). Also, the 40m summary pages have been down for the past 3 weeks but should be up and working soon as the clusters are now alive.

Ok, after a few minutes of talking to Alex, I got the correct "GUI syntax" through my head, and we now have a simple working green end control which in fact puts signals out through the DAC.

Note to self, do not put any additional filters or controls in the IOP module.  Basically just change the master block with GDS numbers, DCU_ID numbers, etc.  When using a control model, copy the approriate ADC and ADC selector or DAC to the control model.  It will magically be connected to the IOP.

A correct example of a simple control model is attached.

Next in line is to get the adapter boxes for SUS into the new 1X5 rack and get started on SUS filter conversion and figuring out which ADC/DAC channels correspond to which inputs.

TL;DR: I am now able to inject a swept sine and measure a transfer function with python on my Red Pitaya! Attached is a Bode plot for a swept sine from 1 - 30 MHz, going through a band pass filter of 9.5 - 11.5 MHz.

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

• Spent too long trying to get pyRPL to work, do not recommend. The code on their website has a lot of problems (like syntax-error level problems), and is ultimately designed to open up and start a GUI, which is not what I want even if it did work.
• Found some code on the git repository of someone at Delft University of Technology, worked better but still not great (oscilloscope/spectrum analyzer functions were alright, but couldn't successfully run a VNA with it, and overcomplicated). Helped me figure out appropriate decimation factors. Realized it was not using the FPGA to get TF data but instead just collecting a lot of time trace data and then taking an FFT in the code to get the TF, which wasn't ideal.
• Eventually switched to using the Red Pitaya SCPI server to talk to the Red Pitaya myself, successful! I inject a swept sine with a for loop that just cycles through frequencies and takes the transfer function at each one.
  • Was originally getting the transfer function by using scipy.signal.csd() and scipy.signal.welch() to get Pxy and Pxx and dividing, and then just finding the closest point in the frequency spectrum to the frequency I was inserting.
  • Switched to doing IQ demodulation myself: where x(t) is the measurement before the band pass filter and y(t) is the measurement after, taking the mean of (x(t) * cos(2pi*freq)) = a1, mean(x*sin()) = a2, mean(y*cos()) = b1, mean(y*sin()) = b2, and then TF(freq) = (b1 + i b2)/(a1 + i a2).
  • Unfortunately still taking time trace data and then calculating the TF instead of using the FPGA, but I have not found anything online indicating that people are able to get VNA capabilities on the Red Pitaya without collecting and sending all the time trace data... I'm still not sure if that's actually a Red Pitaya capability yet.

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

To do:

• Will go take measurements of the AUX laser loop with the RPi! Have a good diagram of when I did it with the SR785 so it shouldn't be too hard hopefully.
• Figure out how to get coherence data!!
• Figure out how to get the RPi on the wifi. Right now I'm just plugging the RPi into my computer. Paco and I were working on this before and had trouble finding old passwords... Hopefully will not be too much of a roadblock.

                 Boom!

Steve and Koji

- We removed old ITMX/Y from the chambers. Now they are temporarily placed on the flow table at the end. Steve is looking for nice storages for the 5inch optics.

- We wiped new ITMX/Y by isopropanol as they were dusty.

- We put them into the corresponding towers. Checked the balancing and magnet arrangements with the OSEMs. They were totally fine.

- We clamped the mirrors by the EQ stops. Wrapped the towers by Al foils.

Tomorrow we will put them into the chambers.

I'm currently working on a set of scripts which will be able to parse a "template" mdl file, replacing certain key words, with other key words, and save it to a new .mdl file.

For example  you pass it the "template" file of scx.mdl file (suspension controller ETMX), and the keyword ETMX, followed by an output list of scy.mdl ETMY,  bs.mdl BS, itmx.mdl  ITMX, itmy.mdl ITMY, prm.mdl PRM, srm.mdl SRM.  It produces these new files, with the keyword replaced, and a few other minor tweaks to get the new file to work (gds_node, specific_cpu, etc).  You can then do a couple of copy paste actions to produce a combined sus.mdl file with all the BS, ITM, PRM, SRM controls (there might be a way to handle this better so it automatically merges into a single file, but I'd have to do something fancy with the positioning of the modules - something to look into).

I also have plans for a script which gets passed a mdl file, and updates the C1.ipc file, by adding any new channels and incrementing the ipcNum appropriately.  So when you make a change you want to propagate to all the suspensions, you run the two scripts, and have an already up to date copy of memory locations - no additional typing required.

Similar scripts could be written for the DAQ screens as well, so as to have all the suspension screens look the same after changing one set.

I've opened the AP table and I'm working on it.

I re-aligned the Faraday on the AP table. I also aligned the beam to the periscope on the PSL and all the other optics along the beam path.  Now I have a nice NPRO beam at the PLL which overlaps with the PSL beam. The alignment has to be further improved because I see no beat yet.

I wonder if the all the tinkering on the PSL laser done recently to revive the power has changed the PSL NPRO temperature and so its frequency. That could also explain why the beat doesn't show up at the same temperature of the NPRO as I used to operate it. Although I scanned the NPRO temperature +/- 2 deg and didn't see the beat. So maybe the misalignment is the casue.

Not feeling very well right now. I need to go home for a while.

AP table closed at the moment.

NPRO shutter closed

 We definitely changed the PSL NPRO temp while fiddling around, trying to increase the laser power.  I think it's noted in the elog both times that it's happened in the last few months (once when Rana, Koji and I worked on it, and then again when it was just Koji), but we opened up the side of the MOPA box so that we could get at (and change) the potentiometer which adjusts the NPRO temp.  So you may have to search around for a while.

Yes it did.

For long time, the crystal temperature C1:PSL-126MOPA_LTMP was 43~46deg. Now it is 34deg. Try ~10deg lower temperature.

I've opened the AP table and I'm working on it.

Also auxiliary NPRO turned on and mechanical shutter opened.

 Beat found at 30MHz with auxiliary NPRO temperature of 37.19 degrees, vs. ~48 deg as it used to be.

The beat is small (-70dBm). PLL alignment has to be improved.

 PLL alignment improved. Beat amplitude = -10dBm. Good enough.

DC readouts at the PLL photodiode:

V_NPRO = -4.44V

V_PSL = -3.76V

The NPRO beam is attenuated by a N.D.=1 attenuator just before going to the photodiode.

Something strange happened at the last. Right before -10dBm, the amplitude of the beat was about -33dBm. Then I was checking the two interfering beams with the IR card and saw that they overlapped quite well. I then turned my head back to the spectrum analyzer and suddenly the beat was at -10dBm. Not only, but a bunch of new peaks had appeared on the spectrum. Either I inadvertently hit the PD moving it to a better position or something else happened.

Like if someone was making some other modulation on the beam or the modulation depth of the PSL's sidebands had gone up.

I'm working on the AP table. I also opened the auxiliary NPRO shutter. The auxiliary beam is on its path on the AP table and PSL table.

 NPRO shutter closed