40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 40m Log, Page 189 of 341 Not logged in
ID Date Author Type Category Subject
11916   Wed Jan 6 16:40:49 2016 ericqUpdateGeneralNew WiFi router

The new wifi router, a Netgear R6400, has been installed, next to the old one which is disconnected (but not yet removed).

Same SSID, and I've added only the wireless MAC addresses of viviana, paoloa and asia, the three thinkpads inside.

Qualitatively, dataviewer at the X end seems pretty snappy. I'll do some more quantitative comparison of the two routers at some point soon. I will update the wiki, too.

11923   Fri Jan 8 22:37:17 2016 KojiUpdateGeneralNew WiFi router

I configured a new wifi bridge for a GPIB Instruments.

The some facts are described on https://wiki-40m.ligo.caltech.edu/Network

The setting up wasn't so straight forward. I added more details there as a linked page.
One thing I had to do with the martian wifi router was that I had to separate the name of SSIDs for 2GHz and 5GHz networks.

The first establishing the connection takes the most of the time, and the data transfer takes literary nothing.

controls@pianosa|netgpibdata > time ./netgpibdata -i 192.168.113.167 -d AG4395A -a 10 -f meas01 Connecting to host 192.168.113.167, GPIB 10... done. Data will be written into meas01.dat. Parameters will be written into meas01.par. Writing measurement data to file... Writing to the parameter file.

real    0m4.056s user    0m0.068s sys    0m0.020s

12052   Mon Mar 28 22:16:44 2016 KojiUpdateGeneralNew WiFi router

I configured three more mini wifi extender. They are ready to use.

We should add these to the host table (I forgot where it is)

192.168.113.233 NETGEAR_EX3700_1 192.168.113.234 NETGEAR_EX3700_2 192.168.113.235 NETGEAR_EX3700_3 192.168.113.236 NETGEAR_EX3700_4

461   Wed Apr 30 20:48:58 2008 AndreySummaryPEMNew Weather Channels

I created the new channels for the weather station, all letters are capital ones. They are of the form "C1 : PEM-WS_PARAMETER" where "PARAMETER" is temperature, pressure, wind,... characteristics (names are self-obvious).

These new weather channels are indicated on the "Weather Checklist" MEDM screen. Also, units of pressure were changed from Pascal to torr and mbars.

The new weather channels are also visible in Dataviewer. I updated the template, and as an example of Dataviewer data I attach the following 5-hour trends of weather parameters from 3.30PM to 8.30PM on April 30th.
Attachment 1: April30-5hours.png
135   Wed Nov 28 19:02:41 2007 AndreyBureaucracyWIKI-40M UpdateNew WIKI-40M page describing Matlab Suspension Modeling

I created the WIKI-40m page with some details about my today's talk on the 40-m lab meeting.

http://lhocds.ligo-wa.caltech.edu:8000/40m/Modeling_of_suspensions

(or you can go to the main page, http://lhocds.ligo-wa.caltech.edu:8000/40m/ , and click on the link "Modeling of suspensions").

The WIKI-40m page describes my transfer functions and contains the pdf-file of my presentation.
2464   Tue Dec 29 04:28:27 2009 kiwamu, rana, haixingUpdateCamerasNew Video Switch Installed

We have installed the new

Its still in an intermediate state, so don't try to "fix" anything before Kiwamu and I get back onto it in the afternoon.

The status so far is that we have removed the old switch (it was a 256 input x 128 output !! mux)  and installed the new one in the same rack. We have hooked it up to the CDS network and have set up its matrix by using the web interface (i.e. NOT EPICS).

Along the way, we discovered that there is lack of impedance matching in the video all over the 40m. Video signals are RF and need to be treated that way. The PSL signals are T'd around and sent on 50 Ohm cables to high impedance monitor inputs.

We should eliminate any switches besides the new one (called Luciana) and control the PSL's Video Monitor from the main MUX interface. No more Rogue Video Switches.

Another couple of things we have found is about RCR camera.

(1) The long cable which connects the RCR camera box and the video matrix doesn't work. Although the signal is alive and we can see it by the local tv monitor nearby PSL.

(1) The reflected beam going to the camera is too weak to see in the monitor.  We found a strange polarized cube splitter in front of the camera. We should modify it sooner or later.

14391   Wed Jan 9 11:07:09 2019 gautamUpdateVACNew Vac channel logging

Looks like I didn't restart all the daqd processes last night, so the data was not in fact being recorded to frames. I just restarted everything, and looks like the data for the last 3 minutes are being recorded . Is it reasonable that the TP1 current channel is reporting 0.75A of current draw now, when the pump is off? Also the temperature readback of TP3 seems a lot jumpier than that of TP2, probably has to do with the old controller having fewer ADC bits or something, but perhaps the SMOO needs to be adjusted.

 Quote: Gautam and I updated the framebuilder config file, adding the newly-added channels to the list of those to be logged.
Attachment 1: Screenshot_from_2019-01-09_11-08-28.png
2029   Wed Sep 30 17:49:21 2009 JenneUpdateAdaptive FilteringNew UP/DOWN scripts for OAF

[Sanjit, Jenne]

The up and down scripts accessible from the OAF (still C1:ASS-TOP) screen are now totally functional and awesome.  They are under the blue ! button.  The up script can either be for the Seismometers, or the Accelerometers at this time.  The only difference between these 2 is which burt restore file they look at:  the seismometer version puts all 7 seismometer channels in the PEM selecting matrix, while the accelerometer version puts the 6 accelerometer channels in that matrix.  Both scripts also turn on HP_1mHz filters in the ERR_EMPH filter bank and all of the witness filter banks, and the AA32 and AI32 filters in ERR_EMPH, CORR and PEM filter banks.  This makes all of the starting filters the same between the witness paths and the error path.

If you want to use a different combination of sensors, run one of the up scripts, then change the PEM matrix by hand.

The down script disables the output to the optics, and resets the adapted filter coefficients.  DO NOT use this script if you're trying to "pause" the filter to take some nice long averages.

17099   Tue Aug 23 14:59:15 2022 JCUpdateToolsNew Toolbox at Y-End

A new tool box has been placed at the Y-end! Each drawer has its label so PLEASE put the tools back in their correct location. In addition to this, Each tool has its assigned tool box, so PLEASE RETURN all tools to their designated tool box. The tools can be distinguished by a writing or heat shrink which corresponds to the color of the tool chest or location. Photo #2 is an example of how the tools have been marked.

Each toolbox from now on will contain a drawer for the folllowing: Measurements, Allen Keys, Pliers and Cutters, Screwdrivers, Zipties and Tapes, Allen Ball Drivers, Crescent Wrenches, Clamps, and Torque Wrenches/ Ratchets.

4129   Mon Jan 10 16:39:36 2011 josephb, alex, rolfUpdateCDSNew Time server for frame builder and 1PPS

Alex and Rolf came over today with a Tempus LX  GPS network timing server.  This has an IRIG-B output and a 1PPS output.  It can also be setup to act as an NTP server (although we did not set that up).

This was placed at waist height in the 1X7 rack.  We took the cable running to the presumably roof mounted antenna from the VME timing board and connected it to this new timing server.  We also moved the source of the 1PPS signal going to the master timer sequencer (big blue box in 1X7 with fibers going to all the front ends) to this new time server.  This system is currently working, although it took about 5 minutes to actually acquire a timing signal from the GPS satellites.  Alex says this system should be more stable, with no time jumps.

I asked Rolf about the new timing system for the front ends, he had no idea when that hardware would be available to the 40m.

Currently, all the front ends and the frame builder agree on the time.  Front ends are running so the 1 PPS signal appears to be working as well.

12254   Wed Jul 6 17:17:22 2016 PrafulUpdateComputer Scripts / ProgramsNew Tabs and Working Summary Pages

The main C1 summary pages are back online now thanks to Max and Duncan, with a gap in pages from June 8th to July 4th. Also, I've added my new VMon and Sensors tabs to the SUS parent tab on the main pages. These new tabs are now up and running on the July 7th summary page.

Here's a link to the main nodus pages with the new tabs: https://nodus.ligo.caltech.edu:30889/detcharsummary/day/20160707/sus/vmon/

And another to my ldas page with the tabs implemented: https://ldas-jobs.ligo.caltech.edu/~praful.vasireddy/1150848017-1150848317/sus/vmon/

Let me know if you have any suggestions or see anything wrong with these additions, I'm still working on getting the scales to be right for all graphs.

12257   Wed Jul 6 21:05:36 2016 KojiUpdateComputer Scripts / ProgramsNew Tabs and Working Summary Pages

I started to receive emails from cron every 15min. Is the email related to this? And is it normal? I never received these cron emails before when the sum-page was running.

Attachment 1: cron_mail.txt.zip
12258   Wed Jul 6 21:09:09 2016 not KojiUpdateComputer Scripts / ProgramsNew Tabs and Working Summary Pages

I don't know much about how the cron job runs, I'll forward this to Max.

 Quote: I started to receive emails from cron every 15min. Is the email related to this? And is it normal? I never received these cron emails before when the sum-page was running.

Max says it should be fixed now. Have the emails stopped?

12259   Wed Jul 6 21:16:17 2016 Max IsiUpdateComputer Scripts / ProgramsNew Tabs and Working Summary Pages

This should be fixed now—apologies for the spam.

Quote:

I don't know much about how the cron job runs, I'll forward this to Max.

 Quote: I started to receive emails from cron every 15min. Is the email related to this? And is it normal? I never received these cron emails before when the sum-page was running.

12260   Wed Jul 6 21:50:21 2016 KojiUpdateComputer Scripts / ProgramsNew Tabs and Working Summary Pages

It seemed something has been done. And I got cron emails.
Then, it seemed something has been done. And the emails stopped.

15614   Tue Oct 6 07:37:20 2020 yehonathanUpdateWikiNew TIS measurements of 40m Optics

LiYuan has kindly done some Total Integrating Sphere (TIS) measurements on ITMU01 and ITMU02. A summary of the measurement is attached. I uploaded the measurements and some analysis script to nodus at /home/export/home/40m_TIS. I created a Wiki page for the measurements and linked to it from the core optics page.

These TIS measurements look very similar to the TIS of the LIGO optics. Further analysis shows that the scatter loss is 10+/-1.7 ppm for ITMU01 and 8.6+/-0.4 ppm for ITMU02.

In this calculation, a gaussian beam the same size bouncing off the 40m ITMs is assumed to scatter from the mirrors. The error is calculated by moving the beam around randomly with STD of 1mm.

In LiYuan's setup, TIS is measured for scattering angles between 1 and 75 degrees. If we go further and assume that the scatter is Lambertian we can extrapolate that the total loss is 10.9+/-1.9 ppm for ITMU01 and 9.2+/-0.5 ppm for ITMU02.

These measurements complete the loss budget nicely since with the 6ppm loss predicted from the phase maps, the total loss in the arm cavities would be 6+10+10=26ppm which is very close to the 28ppm loss that was measured after the arm cavity optics were cleaned.

Attachment 1: ITMU_sn01-02_tis_1.pdf
9808   Mon Apr 14 17:59:05 2014 JenneConfigurationPEMNew T-240 cable

As payment for borrowing 2 of our seismometers, Zach has made us a new Trillium cable, to go from the granite station to the readout box, which we can put into 1X7, where the PEM ADC is.  To put the T-240 in side the can, and seal it, we need a little jumper cable from the seismometer to the granite, but for now, we can just pass this cable underneath the can.

15997   Tue Apr 6 07:19:11 2021 JonUpdateCDSNew SimPlant cymac

Yesterday Chris and I completed setup of the Supermicro machine that will serve as a dedicated host for developing and testing RTCDS sim models. It is currently sitting in the stack of machines in the FE test stand, though it should eventually be moved into a permanent rack.

It turns out the machine cannot run 10 user models, only 4. Hyperthreading was enabled in the BIOS settings, which created the illusion of there being 12 rather than 6 physical cores. Between Chris and Ian's sim models, we already have a fully-loaded machine. There are several more of these spare 6-core machines that could be set up to run additional models. But in the long term, and especially in Ian's case where the IFO sim models will all need to communicate with one another (this is a self-contained cymac, not a distributed FE system), we may need to buy a larger machine with 16 or 32 cores.

IPMI was set up for the c1sim cymac. I assigned the IPMI interface a static IP address on the Martian network (192.168.113.45) and registered it in the usual way with the domain name server on chiara. After updating the BIOS settings and rebooting, I was able to remotely power off and back on the machine following these instructions.

### Set up of dedicated SimPlant host

Although not directly related to the FE testing, today I added a new machine to the test stand which will be dedicated to running sim models. Chris has developed a virtual cymac which we plan to run on this machine. It will provide a dedicated testbed for SimPlant and other development, and can host up to 10 user models.

I used one of the spare 12-core Supermicro servers from LLO, which I have named c1sim. I assigned it the IP address 192.168.113.93 on the Martian network. This machine will run in a self-contained way that will not depend on any 40m CDS services and also should not interfere with them.

8474   Mon Apr 22 20:17:05 2013 CharlesUpdateISSNew Servo w/switching filters

In my previous post here, a new servo design was discussed. Although the exact design used will depend on the particular noise requirements for the 40m and the Bridge Labs (requirements will be considered separately for each application), I still have to yet to see those formalized. Despite this, I have been simulating an example servo circuit with three switchable stages. The design can be found at: New Servo.

Essentially, this circuit consists of three unity gain buffers that can be switched into different filtering states. Attached is a plot of the transfer function of this particular circuit with successive stages turned on. The curve (0) corresponds to all of the filters being switched off, so the total behavior is that of a unity gain buffer. The curve (1) corresponds to the first stage being turned on with the 2nd and 3rd still acting as unity gain buffers. This first state has a gain of ~80 dB at DC and a pole at ~10 Hz which sets the unity gain crossing at ~100 kHz. The curves (2) and (3) correspond to the second and third stage being turned on, respectively. Each of these stages has a pole at DC (i.e. ~infinite gain) and a zero at 10^4 Hz. For f > 10^4 Hz, these stages have gain ~ 1, as we can see in the transfer function below.

I have also performed some noise analysis of this circuit. Attached are a few plots produced by LISO showing the resistor and op-amp noise separately (it was too cluttered on one plot) at the output node of the servo. Both of these plots have a "Sum Noise" trace, which is the sum for every circuit element and is thus identical between plots. The third noise spectrum included is simply the noise at the output referenced to the input with the previously computed transfer function. I'm not sure if there is a simple method embedded in LISO to reference the noise at the output node to the input, but it should be as simple as numerically dividing the noise spectrum by the transfer function between input and output.

Next, I will be attempting time-dependent simulations of this simple circuit using delayed switches instead of manually controlled ones.

Attachment 1: Servo_v0.1.png
Attachment 2: Example_Filter_-_Transfer_Function_(mag).png
Attachment 3: Example_Filter_-_Transfer_Function_(phase_in_final_state_only).png
Attachment 4: New_Servo_-_Op-Amp_Noise.jpg
Attachment 5: New_Servo_-_Resistor_Noise.jpg
Attachment 6: New_Servo_-_Total_Noise_Input-Referenced.png
11456   Tue Jul 28 20:42:50 2015 JessicaSummaryGeneralNew Seismometer Data Coherence

I was looking at the new seismometer data and plotted the coherence between the different arms of C1:PEM_GUR1 and C1:PEM_GUR2. There was not much coherence in the X arms, Y arms, or Z arms of each seismometer, but there were within the x and y arms of the seismometer.

I think the area we should focus on with filtering is lower ranges, between 0.01 and 0.1, because that it where coherence is most clearly high. It is higher in high frequencies but also incredibly noisy, meaning it probably wouldn't be good to try to filter there.

Attachment 1: Coherence1.png
Attachment 2: Coherence2.png
16727   Tue Mar 15 13:49:44 2022 Ian MacMillanBureaucracyTreasureNew Screwdriver Bits

I have received the new screwdriver bits that will work with the two electric screwdrivers we have. I have distributed them in the 40m. Some are in the electronics stations and some are in the toolbox in the lab. The new electric screwdriver (which looks like a drill but takes typical screwdriver bits) is in the room with the workshop. It is in the blue Makita box. For some reason, lots of the old bits were rounded because of incorrect use. I have thrown the unuseable ones out.

I also requested some screw extractors in case we need them. the one we have now is really big and may not work on smaller screws.

8802   Thu Jul 4 17:14:53 2013 ranaUpdateSUSNew SUS screen

Now that the 3f locking looks so cool for the PRMI, I suppose that the PRMI + arm stuff will be very successful.

At LLO, I've just noticed the screens that they have for the single pendulums / TTs. I'm attaching a screenshot of the one Zach is using for the steering into the OMC. We should grab these and replace our existing SUS screens with them.

Attachment 1: OM1.png
8803   Thu Jul 4 19:37:37 2013 KojiUpdateSUSNew SUS screen

Totally agree. The old suspension screen should be driven away.

16495   Thu Dec 9 00:32:56 2021 TegaUpdateCDSNew SUS medm screen update

The new SUS screen can be reached via sitemap -> IFO SUS button -> NEW ETMX dropdown menu link. Please use and provide feedback. Not sure exactly if we need/want the display screens after the IOP model on the right of the medm screen. I have not been able to locate the corresponding channels but did not want to remove them until I was sure that we don't plan to add these features to our screens. When all bugs have been ironed out, we can use appropriate macro substitution for the other optics.

The next feature to add is the BLRMS to the coil and PD channels. I plan to combine the PEM BLRMS medm implementation with the sus_single_BLRMS model block (located in  /opt/rtcds/userapps/release/cds/c1/models). This way we use the latest BLRMS block in "/opt/rtcds/userapps/release/cds/common/models/BLRMS.mdl" whilst also leveraging the previous work done on the sus_single_BLRMS model, which neatly fits into our current SUS model.

Attachment 1: Screen_Shot_2021-12-09_at_12.29.30_AM.png
Attachment 2: Screen_Shot_2021-12-09_at_12.42.35_AM.png
16496   Thu Dec 9 18:22:36 2021 TegaUpdateCDSNew SUS medm screen update

Work on the medm screen for SUS RMS monitor is ongoing. The next step would be to incorporate this into the SUS medm screen, add the BLRMS model to the SUS controller model, recompile, check that the channels are being correctly addressed, then load the appropriate bandpass and lowpass filters.

Attachment 1: Screen_Shot_2021-12-09_at_6.21.09_PM.png
16500   Fri Dec 10 18:55:58 2021 TegaUpdateCDSNew SUS medm screen update

Turns out the BLRMS monitoring channels for MC1, MC2, MC3, ITMY and SRM already exist in c1pem. So I modified the new SUS screen to display the BLRMS info for the aforementioned optics. Next step is to add the BLRMS monitor for PRM, ITMX, ETMX and ETMY. This would require extending the number of inputs for the "SUS" block in c1pem to accomodate the additional inputs from the remaining optics.

Attachment 1: BLRMS_ITMY_screenshot.png
773   Wed Jul 30 18:45:01 2008 ranaConfigurationSUSNew SUS Drift Technology
I updated the SUS DRIFT screen again, this time with a new feature.

I used Rolf's idea for the AdvLIGO status system and just made the nominals be an
unused sub-field (.SVAL) of the main INMON record. Then I wrote a .csh script to
use tdsavg to average the current INMON vals and insert that as the .SVAL. The next
script should read the .SVAL and set the HIHI and LOLO based on this.

Of course, the values I have just entered are no good because our suspensions are in
a bad state but we can run this script (SUS/setDriftNoms) next time things are good.

And...even better would be if someone were to do the same but used mDV to grab the
minute trend in the past good times instead of the tdsavg (which can't go in the past).
3155   Thu Jul 1 17:05:36 2010 josephb, kiwamu, steveUpdateCDSNew SUS Chassis in rack

Thanks to Steve's work on some L brackets, and Kiwamu's lifting help, we now have a new SUS IO chassis in the new 1X4 rack (formerly the 1Y4 rack), just below the new SUS and LSC computers.  I have decided to call the sus machine, c1sus, and give it IP address 192.168.113.85.  We also put in a host interface adapter, OSS-HIB2-PE1x4-1x4 Re-driver HIB, which connects the computer to the IO chassis.

The IP was added to the linux1 name server.  However, the computer itself has not been configured yet.  I'm hoping to come in for an hour or two tomorrow and get the computer hooked up to a monitor and keyboard and get its network connection working, mount /cvs/cds and get some basic RCG code running.

We also ran ethernet cables for the SUS machine to the router in 1X6 (formerly 1Y6) as well as a cable for megatron from 1X3 (formerly 1Y3) to the router, in anticipation of that move next week.

During the day, I realized we needed 2 more ADCs, one of which I got from Jay immediately.  This is for two 110Bs and 4 Pentek ADCs.  However, there's a 3rd 110B connected to c0dcu1 which goes to a BNC patch panel.  Original Jay thought we would merge that into 4 pin lemo style into the 2nd 110B associated with the sus front ends.  We've decided to get a another ADC and adapter.  That will have to be ordered, and generally take 6-8 weeks.  However, it may be possible to "borrow" one from another project until that comes in to "replace" it.  This will leave us with our BNC patch panel and not force me to convert over 20 cables.

I also discovered we need one Contec DIO-1616L-PE Isolated Digital IO board for each Chassis, which I wasn't completely aware of.  This is used to control the ADCs/DACs adapter boards in the chassis.  It means we need still need to put a Binary Output board in the c1iscex chassis.  Hopefully the chassis as they come in come from Downs continue to come with the Contec DIO-1616L-PE boards (they have so far).

The current loadout of the SUS chassis is as follows:

Treton Board

Far left slot, when looking from the front has the OSS-MAX-EXP-ELB-C board, used to communicate with the c1sus computer.

Slot 2 DAC PMC66-16AO16-16-F0-OF

Slot 3-6 BO Contec DIO-32L-PE Isolated Digital Output board

Slot 8-9 DAC PMC66-16AO16-16-F0-OF

Slot 12 Contect DIO-1616L-PE Isolated Digital IO board

Back  Board

2820   Tue Apr 20 18:02:22 2010 JenneUpdateCOCNew SRM and PRM Hung

[Jenne, Steve]

We removed the old SRM and PRM from their cages, and are temporarily storing them in the rings which we use to hold the optics while baking.  Steve will work on a way to store them more permanently.

We then hung the new SRM (SRMU03) and new PRM (SRMU04) in the cages.  We were careful not to break the wires, so the heights will not have changed from the old heights.

The optics have not been balanced yet.  That will hopefully happen later this week.

15322   Fri May 8 14:27:25 2020 HangUpdateBHDNew SRC gouy phase

[Jon, Hang]

After updating the 40 m finesse file to incorporate the new SRC length (and the removal of SR2), we find that the current SRM radius curvature is fine. Thus a replacement of SRM is NOT required

Basically, the new one-way SRC gouy phase is 11.1 deg according to Finesse, which is very close to the previous value of 10.8 deg. Thus the transmode spacing should be essentially the same.

In the first attached plot is the mode content calculated with Finesse. Here we have first offset DARM by 1m deg and misaligned the SRM by 10 urad. From the top to bottom we show the amplitude of the carrier fields, f1, and f2 sidebands, respectively. The red vertical line is the nominal operating point (thanks Koji for pointing out that we do signal recycling instead of extraction now). No direct co-resonance for the low-order TEM modes. (Note that the HOMs appeared to also have peaks at \phi_srm = 0. This is just because the 00 mode is resonant and thus the seed for the HOMs is greater. )

We can also consider a clean case without mode interactions in the second plot. Indeed we don't see co-resonances of high order modes.

Attachment 1: mode_spec_finesse.pdf
Attachment 2: mode_spec_ideal.pdf
15729   Thu Dec 10 17:12:43 2020 JonUpdate New SMA cables on order

As requested, I placed an order for an assortment of new RF cables: SMA male-male, RG405.

• x3 12"
• x3 24"
• x2 48"

They're expected to arrive mid next week.

15739   Sat Dec 19 00:25:20 2020 JonUpdate New SMA cables on order

I re-ordered the below cables, this time going with flexible, double-shielded RG316-DS. Jordan will pick up and return the RG-405 cables after the holidays.

 Quote: As requested, I placed an order for an assortment of new RF cables: SMA male-male, RG405. x3 12" x3 24" x2 48"
15740   Sat Dec 19 02:42:56 2020 KojiUpdate New SMA cables on order

Our favorite (flexible) RF cable is Belden's 1671J (Jacketed solder-soaked coax cable). It is compatible RG405. I'm not sure if there is off-the-shelf SMA cables with 1671J.

7018   Tue Jul 24 12:06:41 2012 MashaUpdatePEMNew RMS channels, New C1PEM Overview

As Jenne suggested last night, I changed the C1PEM overview in Epics. Previously, the C1PEM_OVERVIEW.adl screen had two separate visualizations, one for LP and one for BP for each channel. I changed the format so that there is only one frame per RMS channel, showing all of the input and output as before, but continuously, to demonstrate the actual RMS process.

First, the input is bandpass filtered, then multiplied by itself (squared), then lowpass filtered, and then square rooted to yield the final output. I have kept the previous files, but have applied this new format to all of the RMS ACC*, GUR1, GUR2, and STS1 channels.

As Rana suggested yesterday, I made channels for 0.01 - 0.03 Hz and 0.03 - 0.1 Hz, and created filters for them, which I will work on some more now.

Attachment 1: NewRMSFrames.png
16807   Sun Apr 24 13:17:08 2022 TommyUpdateElectronicsNew RFSoC2x2 Overlay

We recieved an overlay from Chris Stoughton which he used for a ZCU11 board. The overlay is supposed to be compatible with the RFSoC 2x2 and help enable the Multi-Tile Synchronization (MTS) we need. He also provides a .py with the necessary low level connection to the board and its memory along with a few sample notebooks.

Progress So Far:

• The overlay loads properly and in reasonable time.
• We can set the mixer and dac frequencies. However, it is unclear what event_src Chris wanted for the adc mixers. It seems that he was using event_src_immediate (possibly unintenionally) which is not an available adc mixer setting in our board. Instead, we set the event source to "Tile" and will later determine if this is an issue.
• We then go to get data from the buffer. There are two functions called: capture and transfer. These are called on the pynq DMA. Capture runs fine but we get stuck during the transfer at dma.revchannel.wait(). This issue has not been resolved.
4636   Thu May 5 13:13:32 2011 JenneUpdateLSCNew RFPD screens are in

Joe helped me compile the lsc simulink model, and now we have R&D phase rotation.

Right now, we have to do our own math, and figure out what relative phase to put in.  Soonly, I'll figure out how to do subtraction, and we can put in the measured value.

More details when I'm not running around like crazy...

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

Okie dokie.  Last night I had modified the c1lsc.mdl to accommodate the R & D phase rotation.  I also made pretty new screens.  This morning however, the adventures began.....

Under Joe's supervision, I ran "make c1lsc".  The error that came up was something about things not being connected.  Joe assures me that this is a temporary problem, that Rolf is already working on.  The reason is that right now the LSC model is "flat", i.e. it doesn't have a bunch of sub-boxes and sub-screens in the simulink model.  Somehow this causes badness.  Joe stuck all the guts of the LSC model into a sub-model.  He then enabled "top_names", which makes the channels use the name of the sub-model, not the sub-model AND the main model (so since the sub-model is called LSC, our channels are just C1:LSC-OTHER_STUFF, rather than C1:LSC-LSC_OTHER_STUFF).  This fixed things so that the compiling worked (when we did "make c1lsc").  The one other thing that we changed was to delete all of the little "Outs" that were attached to EPICS readouts.  These are unneccessary and don't go anywhere, and when we made the sub-model, they made a bunch of empty outputs (unconnected outs on the main simulink model).  So, after doing that, we were able to compile, and do "make install-c1lsc", and all was good in the world.  Mostly.

Joe then noticed that I was using the CDS part "cdsPhase", which only takes one phase input.  I wanted "cdswfsPhase", which actually does the R&D phase rotation that we want.  Perhaps Alex/Rolf/whoever should change the name of that CDS part.  We switched all of the cdsPhase blocks to be cdswfsPhase, and recompiled.  All was still good in the world.  Mostly.

The last thing that was funny was that when I wanted to execute the medm screens, they would still look at the old _IQ_MTRX_1_1 and _IQ_MTRX_2_1 values, rather than the newly defined _PHASE_R and _PHASE_D channels, even though while editing the medm screen, it looked like it was pointing to the right place.  Anyhow, I opened the text file version of the C1LSC_PDX.adl, and changed the channel names to the _R and _D versions by hand.  I don't know if we edit the screens and run generate_screens.py again, if we'll have to re-edit the .adl text files.

After fixing this, all really was good in the world.

Perhaps though, this making a subsystem business broke the filters somehow?  Foton is looking at the wrong text file now?  Something?  The filters are all still there, they just got moved down a level.  Joe said that he and Rolf are on it, and he should be able to put the LSC model back to being "flat" in the next few days.

10867   Wed Jan 7 12:15:17 2015 manasaUpdateGeneralNew RF cables

I was working around the PSL table this morning.

1. I have fibers running from the Y end and the PSL table to the Optical Fiber Module for Frequency Offset Locking.

Y+PSL out power is ~200uW. From the transimpedance and responsivity specs of the RFPD (ThorLabs FPD310), we expect ~100uW or -10dBm RF power. I have not hooked up the RF output to a spectrum analyser to confirm this as yet.

2. Also, Steve and I ran RF cables (LMR-195A) from the PSL table to the FC module on the IOO rack.

11403   Mon Jul 13 14:08:10 2015 ericqUpdateElectronicsNew RF amps, housed

I made a little box for the new RF amplifiers we'll be using for the green beatnotes, to keep things tidy on the PSL table. They are both Minicircuits model ZHL-3A-S.

I took TFs of their response with the agilient analyzer (calibrating out the cables, splitters, etc.) Powered at +24V, we get a solid ~27dB of gain up to around 200MHz, which is fine for our needs. The phase profile is mostly a 6-7 nsec delay, which is negligible for ALS. Data files are attached.

Koji looked at me like I was crazy for using a BNC connector for the DC power. I haven't yet been able to find panel mount banana connectors, but when I do, I'll replace it.

Banana'd:

Attachment 1: ampBox.jpg
Attachment 2: ampTFs.png
Attachment 3: ampTFs.zip
Attachment 4: ampBox2.jpg
2882   Wed May 5 16:32:39 2010 AlbertoUpdate40m UpgradingNew REFL55 PD, 11MHz rejection

Here's the (calibrated) transimpedance of the new REFL55 PD.

T(55.3) / T_(11.06) = 93 dB

2989   Wed May 26 10:58:29 2010 josephbUpdateCDSNew RCG checkout for use with all machines plus some issues

Now that we have multiple machines we'd like to run the new front end code on, I'm finding it annoying to have to constantly copy files back and forth to have the latest models on different machines.  So I've come to the conclusion that Rana was right all along, and I should working somewhere in /cvs/cds/caltech which gets mounted by everyone.

However, this leads to the svn problem: I.e. I need recent code checked out from the RCG repository, but our current /cvs/cds/caltech/cds/advLigo directory is covered by the 40m SVN.  So for the moment, I've checked out the advLigoRTS from https://redoubt.ligo-wa.caltech.edu/svn/advLigoRTS/trunk into /cvs/cds/caltech/cds/advLigoRTS.  This directory will be kept as up to date as I can keep it, both by running svn update to get Alex/Rolf's changes and on my end by keeping the new and updated models.  It will remain linked the RCG repository and not the 40m repository.  At some point a better solution is needed, but its the best I can come up with for now.

Also, because we are starting to compile on different machines sometimes, you may run into a problem where a code won't run on a different machine.  This can be fixed by commenting out some lines in the startup script.  Go to the /cvs/cds/caltech/scripts directory.  Then edit the associated startSYS file by commenting out the lines that look like:

if [ hostname != megatron ]; then
echo Cannot run basename \$0 on hostname computer
exit 1
fi

Unfortunately, this gets reverted each time "make SYS" and "make install-SYS" gets run.

The other issue this leads to is that some machines don't have as many CPUs available as others.  For example our new thin 1U machines have only 4 dual cores (8 CPUs total).  This means the specific_cpu setting of any of the codes cannot be higher than 7 (cores being numbered 0 through 7).  Core 0 is reserved for the real time kernel, and Core 1 will be used on all machines for the IO processor. This leaves only cores 2 through 7 available for models to use which include LSC, LSP, SUS, SUP, SPY, SCY, SPX, SCX, OMC, OMP, OAF, OAP?, IOC, IOP.  Since there are more than 6 models, duplication in final production code of specific_cpus will be necessary.  Codes which are all running on Megatron at one point will have to be rebuilt with new specific_cpu values when run on the actual final machine.

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

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

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

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

16772   Tue Apr 12 09:05:21 2022 JordanUpdateVACNew Pressure Gauge Install/Pump Spool Vent

Today, Tega and I would like to vent the pump spool an dinstall the new FRG-400 Agilent Pressure Gauges (per elog 15703). The attached picture shows the volume needed to be vented highlighted in red, and the gauges that need to be replaced/removed (purple dot next to the name).

The vent plan is as follows:

Open RV2

Open VM3

Open V7

Open V4

Shut down TP2

Install new gauges

Attachment 1: Screenshot_2022-04-12_08-42-33.png
Attachment 2: 81CB0936-1B19-4722-8A32-C3DC1D1FBC21.heic
Attachment 3: 2262ECEF-6200-4E95-8E32-C83CB9EB4F17.heic
Attachment 4: B5712B34-ECF6-43BE-BCB2-38CD775CF653.heic
Attachment 5: BEE14A07-976A-45C2-82A0-1774D377941E.heic
16773   Wed Apr 13 12:50:07 2022 TegaUpdateVACNew Pressure Gauge Install/Pump Spool Vent

[Jordan, JC, Tega]

We have installed all the FRGs and updated the VAC medm screens to display their sensor readings. The replacement map is CC# -> FRG#, where # in [1..4] and PRP1 -> FRG5. We now need to clean up the C1VAC python code so that it is not overloaded with non-function gauges (CC1,CC2,CC3,CC4,PRP1). Also, need to remove the connection cables for the old replaced gauges.

4064   Thu Dec 16 10:52:42 2010 josephbUpdateCamerasNew PoE digital cameras

We have two new Basler acA640-100gm cameras.  These are power over ethernet (PoE) and very tiny.

Attachment 1: basler.jpg
2308   Fri Nov 20 13:54:45 2009 AlbertoOmnistructureEnvironmentNew Paper and Cardboard Recycling Bins Introduced to the 40m

The 40m produces a large amount of paper and cardboard waste. It would be worth it if we disposed those kind of garbages for recycling.

I set up two new garbage bins in the lab: one in the control rooms that adds up to the can/bottle recycling bin, and one other one in the office area, next to the printer for general paper disposal.

People in the lab are strongly invited to make use of the two new garbage bins and recycle their paper and cardboard waste.

Boxes can be larger than the garbage bin, so I'd recommend people to crash them before throwing them into the bin.

9773   Tue Apr 1 22:03:44 2014 KojiSummaryASCNew PRM ASC is running

[Koji Jenne]

New PRM ASC was implemented. [to be cnt'd]

9777   Wed Apr 2 19:50:12 2014 KojiSummaryASCNew PRM ASC is running

As the designed ASC filters in this entry had too little phase margins (~10deg), I had to compromise the servo design.

The design was modified and tested again. This will be reported by a following entry.

Incidentally, I have adjusted the demodulation phases of REFL33/55/165 for PRMIsb so that the PRCL is eliminated from the Q signals.

REFL33    125.5 deg -> +136.5 deg
REFL55      45.0 deg -> +  25.0 deg
REFL165   -79.5 deg -> +  44.5 deg

This change of the demod phase for REFL165 was a bit surprising.
I did not check the sign, so it could be -135.5 deg. But still this is a bit change.

9779   Wed Apr 2 23:08:51 2014 KojiSummaryASCNew PRM ASC is running

The new PRM ASC design

Pitch
FM1: zero at 0Hz, pole at 2000Hz, gain at 2000Hz = 2000

FM5: (boost)
zero: f: 0.5Hz q: 1  /  4Hz, q: 2 / f: 1Hz, q: 3
pole: f: 2Hz q: 3  / f: 2.7Hz, q: 2  / f: 1Hz, q: 15

FM9: (HF Roll-off)
pole: f: 40Hz q: 1/Sqrt(2) (2nd order butterworth)

Servo gain: -0.023

Yaw
FM1: zero at 0Hz, pole at 2000Hz, gain at 2000Hz = 2000

FM5: (boost)
zero: f: 0.5Hz q: 1  /  4Hz, q: 2 / f: 1.5Hz, q: 10
pole: f: 1.02Hz q: 10  / f: 3Hz, q: 5  / f: 2Hz, q: 6

FM9: (HF Roll-off)
pole: f: 40Hz q: 1/sqrt(2)

Servo gain: -0.027

The loop gains were adjusted to have the UGFs of 10Hz. The measured openloop transfer functions were compared with the model.
The transfer functions for yaw are well matched. However, the pitch ones don't. It seems that the pitch loop has extra low pass
which I can't locate. The possibility is the analog electronics of the pitch loop.

The effect of the control between 0.3Hz to 3Hz are well represented by the model. The attachment 2 shows the free running
angle fluctuation, the ones with the control engaged, and the estimated spectra. Indeed, the estimated spectra well represent
the measured angular spectra.

Attachment 1: PRM_QPD.pdf
Attachment 2: QPD_spe.pdf
ELOG V3.1.3-