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.

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

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

Will add to post with updates post 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.

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

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.

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

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

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:

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.

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.

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.

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.

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.

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.

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.

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

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

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 1 ADC PMC66-16AI6455A-64-50M

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

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

Slot 7 ADC PMC66-16AI6455A-64-50M

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

Slot 10-11 ADC PMC66-16AI6455A-64-50M

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

Back  Board

Slot 1 ADC adapter D0902006

Slot 2 DAC adapter D0902496-v1

Slot 7 ADC adapter D0902006

Slot 8-9 DAC adapter D0902496-v1

Slot 10-11 ADC adapter D0902006

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.

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.  

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.

 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.

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

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.

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. 

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.

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.

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.

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.

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.

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.

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

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

This should be fixed now—apologies for the spam.

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

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.

The new tool box has came in! I have spent serious time organizing these tools and making it look pretty, so please take care of it! A few things I would like to note.

• The tool box has a power strip, so this is now where we will be charging the power tools. There is also a selected cabinet for the fully charged batteries, bits, and the power tools themselves. 
• The cart next to the tool box had to turned 90 degrees in order to fit the tool box in. While moving this, I noticed this cart is piled with random stuff, let’s tackle this on Wednesdays clean up.
• The tools from this tool box are specifically assigned to the VERTEX area (and the X-End until we get another toolbox.) Please return all the tools in their right tool box and cabinet after usage. 
• The heavier duty equipment such as pipe wrenches, hammers, and power tools will remained stored here in the bottom cabinets. 

Hope you all like it!

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.

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

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.

We have installed the new Video Matrix.

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.

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.

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.

Now the data download from Agilent is super fast!
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

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

Using the techniques employed at LLO, and then by Rana here at the 40m a few weeks ago, Wiener filters have been installed on the inputs of all of the PEM IIR channels which are hooked up to the 110B PEM ADCU.  Some slight modifications have taken place to the code, and it's all been checked in to the 40m svn. 

I have installed the filters into:  All 6 Wilcoxon accelerometers, the Ranger seismometer, and one of the Guralps (GUR1).  The other Guralp is currently connected through the ASS/OAF machine's ADC, so it's not used in this test. The filters are all labeled "Wiener", and are FM1 in the C1:ASS-TOP_PEMIIR_## filter banks.

The first figure below is the output of the Wiener Filter calculation program.  It shows the uncorrected MC_L (black) and the corrected MC_L (red), using the optimal wiener filter.  This is as good as we should be able to do with these sensors in these positions.

The second figure is a DTT shot of me trying out the nifty new filters.  They seem to maybe do a teensy bit on the microseism, but otherwise it's a bit unremarkable.  Hopefully I'll get better subtraction during the day, when the base level for MC_L is higher.  Here, Black is uncorrected MC_L, Red is the corrected MC_L, Blue is the actuation channel, and green is an example seismometer channel to illustrate the ground motion at the time.

For posterity, since it's not all in one elog that I can find, the order of operations to install a Wiener Feed Forward filter is as follows:

1.  (When you can borrow the IFO) Take a very careful TF of the plant, between your actuation point and your error signal readout.  At the 40m, this means between C1:ASS-TOP_SUS_MC1_EXC and C1:IOO-MC_L, since we actuate by pushing on the MC1 coils.  At the sites / future 40m, this would be between the HEPI (or STACIS) and the error signal.  The limit of how good your Feed Forward can do will depend heavily on how good this TF is.  Coherence should be above ~0.95 for all points.  Export this data from DTT as a .txt file, using units "Complex (abs/rad)". 

2. Run fitMC12MCL.m (or equivalent wrapper file) to fit the transfer function you just took with some Poles and Zeros.  Make sure to edit the wrapper file with your new .txt file's name so you're getting a fresh TF (if you've just taken one).

3. (Again, when you can borrow the IFO) Run getMCdata.m (or equivalent) to fetch witness channel data and error signal data.  At the 40m, this usually means C1:IOO-MC_L, and witness sensors which are around the MC chambers.  This data should be taken at a time when the cavity is locked, but pretty much on it's own. (i.e. probably shouldn't have Common Mode feedback on the MC - so the MC should be locked, but not the full IFO, for example.)

4.  Run c1winoiir.m (the main program here, which contains some of these notes). This will take in the TF data you've fit, and the witness channel data you have, and calculate the optimal combination of Wiener filters for your witness channels.  It pre-filters your witness data by your TF, then calculates the Wiener filter.  The resulting FIR filters are saved in a file.

5.  Run firfit.m  This will take the FIR Wiener filters you've just created, and convert them conveniently to IIR filters, in a format to be copied directly into Foton.  For each witness channel, you'll get the IIR filter in 2 formats:  the first is for copying into the Foton .txt file (ex ASS.txt), and the second is for copying into the Foton gui, in the "Command" box on the filter design screen.  The "o" at the end of the copy-able filter indicates to Foton that it is a Z-Plane Online filter.  Copy filters appropriately (there should be a line preceding each set of SOS filter formats to indicate which channel this Wiener filter is for...these channel names are extracted from your getMCdata.m)

6. Save your Foton file, and update your Coefficients in MEDM.  Enable your outputs to actuators, and watch magic happen!

On the To-Do list:

Check the transfer of signal btwn PEMIIR matrix and the 9x1 'matrix' that sends the signals to the SUS inputs.  In the SimuLink, the input to the 9x1 matrix is a bundle of 8 numbers (the 8 outputs of the PEMIIR matrix), but it looks like it only pays attention to the first one.  Need to figure out how to make it realize that it's a bundle, not a single number. 

Also, the OAF up / down scripts don't seem to be working on any of the control room computers.  This needs to be checked in to / fixed (but not tonight....)

EDIT 6 Jan 2010:  Shouldn't have done this.  My bad.  The AA32 is on the other PEM matrix because the Adaptive code runs at 64Hz, so there's downsampling, calculating, and upsampling which goes on.  The Feed Forward path all runs at 2kHz, the regular rate of the ASS/OAF machine.  All of these filters are turned off (although I haven't deleted them from Foton).  Since we're focusing on low frequency stuff and trying to get that to do some subtraction, we're not worrying about the junk at higher frequencies just yet.

I have put AA32 filters into the PEMIIR matrix's input filter banks (ie, C1:ASS-TOP_PEMIIR_##), to match the ones that are in the same places in the regular PEM matrix on the OAF screen. 

I redid the uncorrected vs. corrected MC_L DTT printout, shown below. You can see that there's less junk at higher frequencies in the Blue (actuation channel) trace, which is good.