I got the email from them.  There was apparently a bug that manifested on February 14 2016.  I'll try to software update today.

http://endruntechnologies.com/pdf/FSB160218.pdf
http://endruntechnologies.com/upgradetemplx.htm

I called https://www.endruntechnologies.com/pdf/USM3014-0000-000.pdf  and they said it's very likely just needs a software update. They will email Jamie the details.

No suspention lost damping.

Good job Johannes and Subham.

So, it seems that changing the ETMX for one of the spares will change the contrast defect from ~0.1% to 0.9%. True? Seems like that might be a big deal.

Subham and I have placed the AOM back into the setup right in front of the PMC.

Steps undertaken:

1. The HEPA filters were turned off for some reason. They were turned back on, running at 100% while the enclosure was open.
2. Before the installation, after initial realignment, the PMC TRANSPD read out 748 mV.
3. The laser injection current was dialed down to 0.8 A (just above the threshold, judging by PMC cameras.
4. AOM was attached to the new mount while staying connected to its driver. Put in place, a clamp prevents the cable from moving anywhere near the main beam.
5. Aligned AOM to beam, centering the beam (by eye) on front and back apertures.
6. We then applied an offset to the AOM driver input, eventually increasing it to 0.5 V. A secondary beam became clearly visible below the primary beam.
7. In order to place the razor blade dump (stemming from a box, labeled "cleaned for atm use") before the PMC, where the beam separation was about 3 mm, to make sure we can hit the edged area, we had to place the dump at an angle, facing up.
8. Keeping the 0.5V offset on the driver input, with the lights off, we increased the laser diode current in steps of ~200 mA to its original value of 2.1A, while checking for any IR light scattered from the beam dump. Not a trace.
9. At original current setting, we realigned the beam into the PMC, and obtained 743 mV on the TRANSPD in the locked state.
10. Closed off PSL table, dialed HEPAs down to 50%

The retiling work has finished, Steve and I restored the N2 supply configuration to its normal state. The sequence of steps followed was:

1. Went to the X end and closed the following valves, roughly in this order: VAEE, VAEV, VABS, VABSCI, VASV, VASE, V4, V1.
2. Checked the RPM on the various turbo pump controllers to make sure they were in their nominal states
3. Disconnect the electrical connections to V1, V4, V5 and VA6 - just to make sure some spurious signal doesn't unintentionally open any of these valves while we are mucking around with the N2 supply
4. Close the valves on the N2 cylinders in the drill room. Disconnect the temporary nitrogen line (at this point, the N2 pressure to the IFO valves goes down from ~7-PSI to 0), reconnect the old supply chain, taking care that we aren't unintentionally loosening any of the Swagelock connections while unscrewing stuff
5. Replaced one of the N2 cylinders that was running low.
6. Reopen the cylinders, restore N2 pressure to IFO valves to ~70PSI.
7. Do steps 1-3 in reverse: i.e. reconnect power to all valves, open them in the reverse order we closed them while monitoring the state of the various turbo pumps. 
8. Acknowledged the error message on the C0VAC medm screen

Note: the valve isolating the RGA automatically shutoff during this work, possibly because it detected a pressure above its threshold - after checking the appropriate pressure gauges, we reopened this valve as well. 

The attached screenshot suggests that everything went as planned and that the vacuum system is back to normal...

This was an oversight on my part. I've updated the .kat file to have all the optics have the RoC as per the phase map page. I then re-did the tracing of the Y arm cavity mode to determine the appropriate beam parameters at the laser in the simulation, and repeated the sweep of RoC of ETMX while holding RoC of ETMY fixed at 60.2m. The revised contrast defect plot is attached (this time it is the contrast defect, and not the contrast, but since I was running the simulation again I thought I may as well change the plot). 

As per this plot, if the ETMX RoC is ~54.8m (the closer of the two spares to 60.2m), the contrast defect is 0.9%, again in good agreement with what the note linked in the previous elog tells us to expect...

That sounds weird. If the ETMY RoC is 60 m, why would you use 57.6 m in the simulation? According to the phase map web page, it really is 60.2 m.

There was only one razor blade beam dump labeled for atmospheric use left, but that's all we need. Steve is working on restocking. I placed the modified AOM mount on the PSL table near its intended location (near the AOM where it doesn't block any beams).

Things to keep in mind:

• The laser power needs to be turned down for the installation of the AOM. Current laser settings are: Crystal Temperature: 29.41 C, Diode Current: 2.1 A.
• The AOM driver must not be left unterminated when turned on (which it currently is and will be).
• The HEPA filters are currently running at ~50%. While the PSL enclosure is open for the work we'll set them to 100% and lower them after a job well done.

The setup:

The AOM has a deflection angle of about 20 mrad, which requires about 10cm of path for a separation of 2mm of the two beams. I need to survey closer and confirm, but I hope I can fit the beam dump in before the PMC (this of course also depends on the spot size). Alternatively, the PMC hopefully isn't resonant for anything remotely relevant at 80MHz offset, in which case we can also place the beam dump in its reflection path.

So this is the plan:

• Determine coupling efficiency into PMC for reference
• Turn down laser power
• No signal on AOM driver modulation input
• Mount AOM, place in beam path, and align
• Correct alignment into PMC?
• Secondary beam detectable? Adjust modulation input and laser power until detectable.
• Find a place for beam dump
• Confirm that primary beam is not clipping with PMC
• Turn up laser power
• Determine coupling efficiency with restored power to compare

Any thoughts? Based on the AOMs resting place I assumed that it is supposed to be installed before the PMC, but I'm actually not entirely sure where it was sitting before.

After poking at the new configuration more, it also started to show instability.  I couldn't figure out how to make test points or excitations available in this configuration, and adding in the full set of test point channels, and trying to do simple things like plotting channels with dtt, the frame writer (fw) would fall over, apparetnly unable to keep up with the broadcast from the dc.

I've revered everything back to the old semi-working fb configuration, and will be kicking this to the CDS group to deal with.

Summary

In a previous elog, I demonstrated that the RoC mismatch between ETMX and ETMY does not result in appreciable degradation in the mode overlap of the two arm modes. Koji suggested also checking the effect on the contrast defect. I'm attaching the results of this investigation (I've plotted the contrast,   rather than the contrast defect 1-C).

Details and methodology

• I used the same .kat file that I had made for the current configuration of the 40m, except that I set the reflectivities of the PRM and the SRM to 0. 
• Then, I traced the Y arm cavity mode back to the node at which the laser sits in my .kat file to determine what beam coming out of the laser would be 100% matched to the Y arm (code used to do this attached)
• I then set the beam coming out of the laser for the subsequent simulations to the value thus determined using the gauss command in finesse.
• I then varied the RoC of ETMX (I varied the sagittal and tangential RoCs simultaneously) between 50m and 70m. As per the wiki page, the spare ETMs have an RoC between 54 and 55m, while the current ETMs have an RoC of 60.26m and 59.48m for the Y and X arms respectively (I quote the values in the "ATF" column). Simultaneously, at each value of the RoC of ETMX, I swept the microscopic position of the ETMX HR surface through 2pi radians (-180 degrees to 180 degrees) using the phi functionalilty of finesse, while monitoring the power at the AS port of this configuration using a pd in finesse. This guarantees that I sweep through all the resonances. I then calculate the contrast using the above formula. I divided the parameter space into a grid of 50 points for the RoC of ETMX and 1000 points for the microscopic position of ETMX. 
• I fixed the RoC of ETMY as 57.6m in the simulations... Also, the maxtem option in the .kat file is set to 4 (i.e. higher order modes with indices m+n<=4 are accounted for...)

Result:

Attachment #1 shows the result of this scan (as mentioned earlier, I plot the contrast C and not the contrast defect 1-C, sorry for the wrong plot title but it takes ~30mins to run the simulation which is why I didn't want to do it agian). If the RoC of the spare ETMs is about 54m, the loss in contrast is about 0.5%. This is in good agreement with this technical note by Koji - it tells us to expect a contrast defect in the region of 0.5%-1% (depending on what parameter you use as the RoC of ETMY). 

Conclusion:

It doesn't seem that switching out the current ETM with one of the spare ETMs will result in dramatic degradation of the contrast defect...

Misc notes:

1. Regarding the phase command in Finesse - EricQ pointed out that the default value of this is 3, which as per the manual could give unphysical results sometimes. The flags "0" or "2" are guaranteed to yield physical results always according to the manual, so it is best to set this flag appropriately for all future Finesse simulaitons. 
2. I quickly poked around inside the cabinet near the EX table labelled "clean optics" to see if I could locate the spare ETMs. In my (non-exhaustive) search, I could not find it in any of the boxes labelled "2010 upgrade" or something to that effect. I did however find empty boxes for ETMU05 and ETMU07 which are the ETMs currently in the IFO... Does anyone know if I should look elsewhere for these?
   EDIT 17Jun2016: I have located ETMU06 and ETMU08, they are indeed in the cabinet at the X end...
3. I'm attaching a zip file with all the code used to do this simulation. The phase flag has been appropriately set in the (only) .kat file. setLaserQparam.py was used to determine what beam parameter to assign to be perfectly matched to the Y arm. modeMatchCheck_ETM.py was used to generate the contrast as a function of the RoC of ETMX.
4. With regards to the remaining checks to be done - I will post results of my investigations into the HOM scans as a function of the RoC of the ETMs and also the folding mirrors shortly... 

I have installed a ZFL-500LN on the RF output of POY11. This should reduce the effect of the CM board voltage offsets by increasing the size of the error signal coming into the board. Checking with an oscilloscope at the LSC rack, the single arm PDH peak to peak voltage was something like 4mV, now it is something like 80mV. 

The setup is similar to the REFL165 situation, but with the amplifier in proximity with the PD, instead of at the end of a long cable at the LSC rack. 

The PD RF output is T'd between an 11MHz minicircuits bandpass filter and a 50 Ohm terminator (which makes sure that signals outside of the filter's passband don't get reflected back into the PD). The output of the filter is connected directly to the input of the ZFL-500LN, which is powered (temporarily) by picking off the +15V from the PD interface cable via Dsub15 breakout. (I say temporarily, as Koji is going to pick out some fancy pi-filter feedthrough which we can use to make a permanent power terminal on the PD housing.)

The max current draw of this amplifier is 60mA. Gazing at the LSC interface (D990543), I think the +15V on the DSUB cable is being passed from the eurocard crate; I don't see any 15V regulator, so maybe this is ok...

The free swinging PDH signal looked clean enough on a scope. Jamie is doing stuff with the framebuilder, so I can't look at spectra right now. However, turning the POY whitening gain down to +18dB from +45dB lets the Y arm lock on POY with all other settings nominal, which is about what we expect from the nominal +23dB gain of the amplifier.

I would see CM board offsets of ~5mV before, which was more a little more than a linewidth before this change. Now it will be 5% of that, and hopefully more manageable.

Using the ALS green beat and armlength feedback I mapped an IR resonance of the Y-Arm by stepping through a ramp of offset values.

First I optimized the IR alignment with the dither scripts while LSC kept the arm on resonance, and then transitioned the length control to ALS. The beat frequency I obtained between the Y-arm green and the PSL was about 25 MHz. Then I applied a controlled ramp signal (stepping through small offset increments applied to LSC-ALSY_OFFSET, while logging the readback from channels LSC-TRY_OUT16 and ALS-Y_FC_SERVO_INMON with an averaging time of 1s.

The plots show the acquired data with fits to  and , respectively.

The fits, weighted with inverse rms uncertainty of the data points as reported by the cds system, returned HWHM = 0.6663 ± 0.0013 [offset units] and m = -0.007666 ± 0.000023 [MHz/offset unit], which gives a combined FWHM = 10,215 ± 36 Hz. The error is based purely on the fit and does not reflect uncertainties in the calibration of the phase tracker.

This yields a finesse of 388.4 ± 1.4, corresponding to a total loss (including transmissivities) of 16178 ± 58 ppm. These uncertainties include the reported accuracies of FSR and phase tracker calibration from elog 9804 and elog 11761.

The resulting loss is a little lower than that of elog 11712, which was done before the phase tracker re-calibration. Need to check for consistency.

NOT finished, last edited 7-7

PSL, BS, ITMY and ETMX the illuminators were left on over night.

I wish to have stereo audio output for the DAF module. Hence, there needs to be a second output from the DAF. I added this second output to the model. Following are the details:

FiBox: It consists of two analog inputs which are digitized and multiplexed and transmitted optically. (only 1 fiber is needed due to multiplexing). Attachment 1 shows the fibox with its 2 analog inputs (one of which, is connected), and 1 fiber output. The output of the DAF goes to the FiBox. Until today, the Fibox recieved only 1 analog input. This analog signal comes from the DAC-8 (count starting from 0), which is located at "CH 1 OUT" SMA output in the "MONITORS" bin on the racks (attachment 2).

I have added another output channel to the DAF model both in software and in hardware. The DAF now also uses DAC-9 analog output which goes to the second analog input of the FiBox. The DAC-9 output is located at "CH 2 OUT" SMA output in the "MONITORS" bin on the racks (attachment 4).

After making the changes, the Fibox is shown in attacment 3.

Testing: The LSC input on passing through the DAF block is given through two different DAC outputs, to the same Fibox channel (one after the other), and the output is heard. More concrete testing will be done tomorrow. It will be as follows:

1) Currently, I need to search for a suitable cable that would connect the second channel of the output fibox to the audio mixer. After doing this, end to end testing of both channels will be done.

2) I could not access the AWG, probably because the DAQ was offline today afternoon. Using a signal from the AWG will give a more concrete testing of the stereo output.

3) After this, I will separate the two channels of the stereo completely (currectly they are seperated only at the DAF output stage)

4) I also will edit the medm gui appropriately.

Just to be clear, there's still quite a bit of work to fully transition the 40m to this new system/configuration.  Once we determine a good configuration we need to complete the install, and modify the setup to run the two binaries instead of just the one.  The data is also being written to a raid on the new fb1, and we need to decide if we should use this new raid, or try to figure out how to move the old jetstor raid to the new fb1 machine.

Visual inspection of rooftop GPS antennae:

The 2 GPS antennas are located on the north west corner of CES roof. Their condition looks well weathered. I'd be surprised if they work.

The BNC connector of the 1553 head is inside of the conduit so it is more likely to have a better connection than the other one.

I have not had a chance to look into the "GPS Time Server" unit.

Very encouraging results from the test last night.  The new configuration did not crash once overnight, and seemed to write out full, second trend, and minute trend frames without issue.  However, full validity of all the written out frames has not been confirmed.

overview

The configuration under test involves two separate daqd binaries instead of one.  We usually run with what is referred to as a "framebuilder" (fb) configuration:

• fb: a single daqd binary that:
  • collect the data from the front ends
  • coallate full data into frame file format
  • calculates trend data
  • writes frame files to disk.

The current configuration separates the tasks into multiple separate binaries: a "data concentrator" (dc) and a "frame writer" (fw):

• dc:
  • collect data from front ends
  • coallate full data into frame file format
  • broadcasts frame files over local network
• fw:
  • receives frame files from broadcast
  • calculates trend data
  • writes frame files to disk

This configuration is more like what is run at the sites, where all the various components are separate and run on separate hardware.  In our case, I tried just running the two binaries on the same machine, with the broadcast going over the loopback interface.  None of the systems that use separated daqd tasks see the failures that we've been seeing with the all-in-one fb configuration (and other sites like AEI have also seen).

My guess  is that there's some busted semaphore somewhere in daqd that's being shared between the concentrator and writer components.  The writer component probably aquires the lock while it's writing out the frame, which prevents the concentrator for doing what it needs to be doing while the frame is being written out.  That causes the concentrator to lock up and die if the frame writing takes too long (which it seems to almost necessarily do, especially when trend frames are also being written out).

results

The current configuration hasn't been tweaked or optimized at all.  There is of course basically no documentation on the meaning of the various daqdrc directives.  Hopefully I can get Keith Thorne to help me figure out a well optimized configuration.

There is at least one problem whereby the fw component is issuing an excessively large number of re-transmission requests:

2016-06-15_09:46:22 [Wed Jun 15 09:46:22 2016] Ask for retransmission of 6 packets; port 7097
2016-06-15_09:46:22 [Wed Jun 15 09:46:22 2016] Ask for retransmission of 8 packets; port 7097
2016-06-15_09:46:22 [Wed Jun 15 09:46:22 2016] Ask for retransmission of 3 packets; port 7097
2016-06-15_09:46:22 [Wed Jun 15 09:46:22 2016] Ask for retransmission of 5 packets; port 7097
2016-06-15_09:46:22 [Wed Jun 15 09:46:22 2016] Ask for retransmission of 5 packets; port 7097
2016-06-15_09:46:22 [Wed Jun 15 09:46:22 2016] Ask for retransmission of 5 packets; port 7097
2016-06-15_09:46:22 [Wed Jun 15 09:46:22 2016] Ask for retransmission of 5 packets; port 7097
2016-06-15_09:46:22 [Wed Jun 15 09:46:22 2016] Ask for retransmission of 6 packets; port 7097
2016-06-15_09:46:23 [Wed Jun 15 09:46:23 2016] Ask for retransmission of 1 packets; port 7097

It's unclear why.  Presumably the retransmissions requests are being honored, and the fw eventually gets the data it needs.  Otherwise I would hope that there would be the appropriate errors.

The data is being written out as expected:

 full/11500: total 182G
drwxr-xr-x  2 controls controls 132K Jun 15 09:37 .
-rw-r--r--  1 controls controls  69M Jun 15 09:37 C-R-1150043856-16.gwf
-rw-r--r--  1 controls controls  68M Jun 15 09:37 C-R-1150043840-16.gwf
-rw-r--r--  1 controls controls  68M Jun 15 09:37 C-R-1150043824-16.gwf
-rw-r--r--  1 controls controls  69M Jun 15 09:36 C-R-1150043808-16.gwf
-rw-r--r--  1 controls controls  69M Jun 15 09:36 C-R-1150043792-16.gwf
-rw-r--r--  1 controls controls  68M Jun 15 09:36 C-R-1150043776-16.gwf
-rw-r--r--  1 controls controls  68M Jun 15 09:36 C-R-1150043760-16.gwf
-rw-r--r--  1 controls controls  69M Jun 15 09:35 C-R-1150043744-16.gwf

 trend/second/11500: total 11G
drwxr-xr-x  2 controls controls 4.0K Jun 15 09:29 .
-rw-r--r--  1 controls controls 148M Jun 15 09:29 C-T-1150042800-600.gwf
-rw-r--r--  1 controls controls 148M Jun 15 09:19 C-T-1150042200-600.gwf
-rw-r--r--  1 controls controls 148M Jun 15 09:09 C-T-1150041600-600.gwf
-rw-r--r--  1 controls controls 148M Jun 15 08:59 C-T-1150041000-600.gwf
-rw-r--r--  1 controls controls 148M Jun 15 08:49 C-T-1150040400-600.gwf
-rw-r--r--  1 controls controls 148M Jun 15 08:39 C-T-1150039800-600.gwf
-rw-r--r--  1 controls controls 148M Jun 15 08:29 C-T-1150039200-600.gwf
-rw-r--r--  1 controls controls 148M Jun 15 08:19 C-T-1150038600-600.gwf

 trend/minute/11500: total 152M
drwxr-xr-x 2 controls controls 4.0K Jun 15 07:27 .
-rw-r--r-- 1 controls controls  51M Jun 15 07:27 C-M-1150023600-7200.gwf
-rw-r--r-- 1 controls controls  51M Jun 15 04:31 C-M-1150012800-7200.gwf
-rw-r--r-- 1 controls controls  51M Jun 15 01:27 C-M-1150002000-7200.gwf

The frame sizes look more or less as expected, and they seem to be valid as determined with some quick checks with the framecpp command line utilities.

I have added Enable buttons for each of the DSP blocks, and labels for the matrix elements. The input matrix takes inputs from each of the 4 channels: ADC1, ADC2, LSC and EXC, and routes them to the audio processing blocks (attachment 2). The output matrix (attachment 3) takes the outputs of the various DSP blocks and routes them to the output and then to the speakers. 

I'm running another overnight test with new daqd software on fb1.  The normal daqd process on fb has been shutdown, and the front ends are sending their signals to fb1.

fb1 is running separate data concentrator (dc) and  frame writer (fw) processes, to see if this is a more stable configuration than the all-in-one framebuilder (fb) that we have been trying to run with.  I'll report on the test tomorrow.

What about ETMY? and are these really microradians or just some made up cal?

Within two hours, it was already all over the place. 

It has been Decided: we will assemble a suspension with the spare ETM optic with the current-generation standoff for installation ASAP. I.e. no new custom parts. We will continue pursuing the new standoff design, but we need our interferometer back.

We generally want to keep the configuration of the 40m close to that of the LIGO sites, which is why we chose BusWorks, and it is also being established as a standard in other labs on campus. Of course any suitable DAQ system can do the job, but to stay relevant we generally try to avoid patchwork solutions when possible. Did you follow Aidan's instructions to the book? I haven't set up a system myself, yet, so I cannot say how difficult this is. If it just won't work with the Raspberry Pi, you could still try using a traditional computer.

Alternatively, following Jamie's suggestions, I'm currently looking into using python for the modbus communications (there seem to be at least a few python packages that can do this), which would reportedly make the interfacing and integration a lot easier. I'll let you know when I make any progress on this.

In preparation for the armloss map I checked the calibration of the Y-Arm ITM and ETM OpLevs with the method originally described in https://nodus.ligo.caltech.edu:8081/40m/1247. I was getting a little confused about the math though, so I attached a document at the end of this post in which I work it out for myself and posteriority. Stepping through an introduced offset in the control filter for the corresponding degree of freedom, I recorded the change in transmitted power and the reading of the OpLev channel with the current calibration. One thing I noticed is that the calibration for ITM PIT is inverted with respect to the others. This can of course be compensated at any point in any readout/feedback chain, but it might be nice to establish some sort of convention where positive feedback to the mirror will increase the OpLev reading.

The calibration factors I get are within ~10% of the currently stored values. The table (still incomplete, need to relate to the current values) summarizes the results:

The individual graphs:

ETM PIT

ETM YAW

ITM PIT

ITM YAW

The math:

The drill room floor will be retiled Thursday, June 16. Temporary nitrogen line set up will allow emptying the hole area.

Ifo room entry will be through control room.

Summary: I am implementing digital audio filtering on various interferometer signals in order to listen to the processed audio which will help in characterizing and noise reduction in the interferometer. following is a summary of the gui i have made towards a general purpose DAF module linked to the LSC. 

Details:  attachment 1 shows the top level overview of the daf module.

The "INPUTS" button shown redirects to the medm screen shown in attachment 2, which is a collection of inputs going into the module.

Each of the buttons shown in "C1DAFI_INPUTS.png" is further linked to various i/o boxes like adc1, adc2, lsc signal and exitation. An example is shown in attachment 3. This is the specific I/O box for the LSC signal.

The field labelled "INPUT_MTRX" is linked to a matrix which routes these 4 inputs to various DSP blocks. Similarly, the "OUTPUT_MTRX" tab is useful for choosing which output goes to the speaker. 

Time and computational load monitoring is done in the "GDS_TP" tab which links to the medm screen shown in attachment 4.

Currently the AGC is successfully implemented as one of the DSP block. The details of the AGC implementation were given in a previous elog: https://nodus.ligo.caltech.edu:8081/40m/12159

I need to make a few changes to the code for Frequency Shifting and Whitening before uploading them on the FE. I will put the details soon.

Some more things that I think need to be added: 

1) "Enable" buttons for each of the DSP blocks.

2) Labels for each of the matrix elements.

3) Further headers and other description for each of the tabs 

About acquiring data: Initially I couldn't start with proper Acromag setup as the Raspberry pi had a faulty SD card slot. Then Gautam gave me a working pi on which I tried to install EPICS. I spent quite a time today but couldn't setup acromag over ethernet.  But, it would be great if we have a USB DAQ card. I have found a good one here http://www.mccdaq.com/PDFs/specs/USB-200-Series-data.pdf It costs around 106$ including shipping (It comes with some free softwares for acquiring data) . Also, I know an another python based 12bit DAQ card (with an inbuilt constant current source) which is made by IUAC, Delhi and more information can be found here http://www.iuac.res.in/~elab/expeyes/Documents/eyesj-progman.pdf  It costs around 60$ including shipping.

About temperature sensing: The RTD which I found on Omega's list is having a temperature resolution of 0.1 deg C. I have also asked them for the one with good resolution. Also according to their reply, they have not performed any noise characteristics study for those RTDs.

 

The PMC transmission slow degration or it's input beam is not stable.

The mode cleaner was misaligned probably due to the earthquake (the drop in the MC transmitted value slightly after utc 7:38:52 as seen in the second plot). The plots show PMC transmitted and MC sum signals from 10th june 07:10:08 UTC over a duration of 17 hrs. The PMC was realigned at about 4-4:15 pm today by rana. This can be seen in the first plot.

ETMX has been jumping around again lately. Just now, I zeroed the ETMX alignment offsets in the SUS model, and centered the ETMX oplev spot via slow machine sliders. OSEM damping is on, oplev damping is off. Let's see how it moves around in the next day or so. 

GPS: 1149635923 

UTC: Jun 10 2016 23:18:26

The GPS receiver (EndRun Technologies box in 1Y5? (rack closest to door)) seems to not coming back up properly after the reboot.  The front pannel says that it's "LKD", but the "sync" LED is flashing instead of solid, and the time of year displayed on the front panel is showing day 6.  The fb1 symmetricom driver and VME timing module are still both seeing day 299, though.  So something may definitely be screwy with the GPS receiver.

Looks like we might have a problem with the IRIG-B output of the GPS receiver.

Rolf came over this morning to help debug the strange symmetricom driver behavior on fb1 with the new Spectracom card.  We restarted the machine againt and this time when we loaded the drive rit was clocking at a normal rate (second/second).  However, the overall GPS time was still wrong, showing a time in October from this year.

The IRIG-B122 output is supposed to encode the time of year via amplitude modulation of a 1kHz carrier.  The current time of year is:

controls@fb1:~ 0$ TZ=utc date +'%j day, %T'
162 day, 18:57:35
controls@fb1:~ 0$ 

The absolute year is not encoded, though, so the symmetricon driver has the year offset hard coded into the driver (yuck), to which it adds the time of year from the IRIG-B signal to get the correct GPS time.

However, loading the symmetricom module shows the following:

...
[ 1601.607403] Spectracom GPS card on bus 1; device 0
[ 1601.607408] TSYNC PIC BASE 0 address = fb500000
[ 1601.607429] Remapped 0xffffc90017012000
[ 1606.606164] TSYNC NOT receiving YEAR info, defaulting to by year patch
[ 1606.606168] date = 299 days 18:28:1161455320
[ 1606.606169] bcd time = 1161455320 sec  959 milliseconds 398 microseconds  959398630 nanosec
[ 1606.606171] Board sync = 1
[ 1606.616076] TSYNC NOT receiving YEAR info, defaulting to by year patch
[ 1606.616079] date = 299 days 18:28:1161455320
[ 1606.616080] bcd time = 1161455320 sec  969 milliseconds 331 microseconds  969331350 nanosec
[ 1606.616081] Board sync = 1
controls@fb1:~ 0$ 

Apparently the symmetricom driver thinks it's the 299nth day of the year, which of course corresponds to some time in october, which jives with the GPS time the driver is spitting out.

Rolf then noticed that the timing module in the VME crate in the adjacent rack, which also receives an IRIG-B signal from the distribution box, was also showing day 299 on it's front panel display. We checked and confirmed that the symmetricom card and the VME timing module both agree on the wrong time of year, strongly suggesting that the GPS receiver is outputing bogus data on it's IRIG-B output, even though it's showing the correct time on it's front panel.  We played around with setting in the GPS receiver to no avail.  Finally we rebooted the GPS receiver, but it seemed to come up with the same bogus IRIG-B output (again both symmetricom driver and VME timing module agree on the wrong day).

So maybe our GPS receiver is busted?  Not sure what to try now.

EQ  5.2 mag at Jun 10, 8:04 am UTC, Borego Spring, CA  ~150 mi away.........no obvoius damage, damping restored, MC is locking, arms are flashing

Eric gave me a psd plot of a signal which would be the input of a channel of the AA filter. the Nyquist freq. is about 32.8kHz.

Following are plots depicting the ratio of the aliased downconverted signal and the signal below 32.8 kHz. The first plot is for (to-be) aliased signal frequencies from 32.8 to 65.5k, and the second plot is for (to-be) aliased signals from 65.5k to 98.3k. In case of the first plot, the 36kHz peak will alias to 29kHz, and is about 30 times (29.5dB) greater than the signal there. Hence, the filter should give about 70dB attenuation there. Since this attenuation is not required by most other frequencies up to 65.5k, an option could be to use a notch filter to remove the frequency peak at 36k, and put a requirement of 45-50 dB attenuation on other frequencies.

In case of the second plot, the frequencies between 90 to 100k again need to be attenuated by more than 70 dB. However, if there is a -20dB/decade slope in stop band, we already have about 10 dB attenuation here as compared to around 32k.

The X axis of both plots is in Hz.

Today I tried to setup Acromag Busworks card. I was able to calibrate and test it over USB but I couldn't test it over ethernet. I'll utilize a few hours tomorrow to test it over ethernet and see if I can make it work. I have also found a few RTDs which I want to use for temperature sensing via four probe method. So, tomorrow I'll get these RTD details revived by Gautam and Steve.

I was wondering if we have a basic DAQ card with maybe 4 channels which is simple to setup like NI DAQ cards.

I've restarted the old daqd on fb until I can figure out what's going on with the symmetricom driver on fb1.

Steve:  Jamie with hair.... long time ago
 

Something is wrong with the timing we're getting out of the symmetricom driver, associated with the new spectracom card.

controls@fb1:~/rtscore/tests/advLigoRTS-40m/src/drv/symmetricom 127$ lalapps_tconvert 
1149538884
controls@fb1:~/rtscore/tests/advLigoRTS-40m/src/drv/symmetricom 0$ cat /proc/gps 
704637380.00
controls@fb1:~/rtscore/tests/advLigoRTS-40m/src/drv/symmetricom 0$ 

The GPS time is way off, and it's counting up at something like 900 seconds/second.  Something is misconfigured, but I haven't figured out what yet.

The timing distribution module we're using is spitting out what appears to be an IRIG B122 signal (amplitude moduled 1 kHz carrier), which I think is what we expect.  This is being fed into the "AM IRIG input" connector on the card.

Not sure why the driver is spinning so fast, though, with the wrong baseline time.  Reboot of the machine didn't help.

Me and Gautam yesterday opened the tilt-free seismometer enclosure to see if we could use the thermocouples and
other things previously used by Megan. But we are planning to get new four-wire RTDs for our work.
For the next day or two, I will be trying to set up Acromag Busworks terminal so that the data logging during
this enclosure development experiment becomes perfect and easy. Johannes has sent me the wiki page URL for the same.

Summary: I am implementing digital audio filtering on various interferometer signals in order to listen to the processed audio which will help in characterizing and noise reduction in the interferometer. Following is an implementation of an Automatic Gain control (AGC) block on an LSC input signal.

Details of AGC: Currently, the AGC code implemented on FE takes input to fill a frame, then calculates the power in each frame and gives an appropriate gain to it, so that the new power content is to the required level. It is then written to the output, frame by frame. The frame is currently a rectangular window. The frame length and hop size can be adjusted. Current values are as follows:

frame length is 512 samples

hop length is 128 samples.

The input and output are delayed by 1 frame.

Details of testing: Attachment 1 shows a simulink diagram of the DAF system. Eric made this and I modified it later on. Testing was done using signal from the "LSC1" channel. Attachments 2 and 3 show aquired input and output of the AGC respectively. Gain of the preamp of the LSC input signal was varied over a total time span of 200 s. Each gain value was kept for a duration of about 20 seconds. The varying power levels can be seen in the input plot.

The output shows a uniform power level throughout.

[EDIT: corrected name of installed card]

We just installed a Spectracom TSyc-PCIe timing card on fb1.  The hope is that this will help with the GPS timeing syncronization issues we've been seeing in the new daqd on fb1, hopefully elliminating some of the potential failure channels.

The driver, called "symmetricom" in the advLigoRTS source (name of product from competing vendor), was built/installed (from DCC T1500227):

Aakash Patil received 40m specific basic safety training.

38 restarts overnight.  Problem definitely not fixed.  I'll be reverting back to old daqd and fb this morning.  Then regroup and evaluate options.

Summary: new daqd code running overnight test on fb1.  Stability issues persist.

The code is from Keith's "tests/advLigoRTS-40m" branch, which is a branch of the current trunk.  It's supposed to include patches to fix the crashes when multiple frame types are written to disk at the same time.  However, the issue is not fixed:

2016-06-07_20:38:55 about to write frame @ 1149392336
2016-06-07_20:38:55 Begin Full WriteFrame()
2016-06-07_20:38:57 full frame write done in 2seconds
2016-06-07_20:39:11 about to write frame @ 1149392352
2016-06-07_20:39:11 Begin Full WriteFrame()
2016-06-07_20:39:13 full frame write done in 2seconds
2016-06-07_20:39:27 about to write frame @ 1149392368
2016-06-07_20:39:27 Begin Full WriteFrame()
2016-06-07_20:39:29 full frame write done in 2seconds
2016-06-07_20:39:43 about to write second trend frame @ 1149391800
2016-06-07_20:39:43 Begin second trend WriteFrame()
2016-06-07_20:39:43 about to write frame @ 1149392384
2016-06-07_20:39:43 Begin Full WriteFrame()
2016-06-07_20:39:44 full frame write done in 1seconds
2016-06-07_20:39:59 about to write frame @ 1149392400
2016-06-07_20:40:04 Begin Full WriteFrame()
2016-06-07_20:40:04 Second trend frame write done in 21 seconds
2016-06-07_20:40:14 [Tue Jun  7 20:40:14 2016] main profiler warning: 1 empty blocks in the buffer
2016-06-07_20:40:15 [Tue Jun  7 20:40:15 2016] main profiler warning: 0 empty blocks in the buffer
2016-06-07_20:40:16 [Tue Jun  7 20:40:16 2016] main profiler warning: 0 empty blocks in the buffer
2016-06-07_20:40:17 [Tue Jun  7 20:40:17 2016] main profiler warning: 0 empty blocks in the buffer
2016-06-07_20:40:18 [Tue Jun  7 20:40:18 2016] main profiler warning: 0 empty blocks in the buffer
2016-06-07_20:40:19 [Tue Jun  7 20:40:19 2016] main profiler warning: 0 empty blocks in the buffer
2016-06-07_20:40:20 [Tue Jun  7 20:40:20 2016] main profiler warning: 0 empty blocks in the buffer
2016-06-07_20:40:21 [Tue Jun  7 20:40:21 2016] main profiler warning: 0 empty blocks in the buffer
2016-06-07_20:40:22 [Tue Jun  7 20:40:22 2016] main profiler warning: 0 empty blocks in the buffer
2016-06-07_20:40:23 [Tue Jun  7 20:40:23 2016] main profiler warning: 0 empty blocks in the buffer

This failure comes when a full frame (1149392384+16) is written to disk at the same time as a second trend (1149391800+600).  It seems like every time this happens daqd crashes.

I have seen other stability issues as well, maybe caused by mx flakiness, or some sort of GPS time synchronization issue caused by our lack of IRIG-B cards.  I'm going to look to see if I can get the GPS issue taken care of so we take that out of the picture.

For the last couple of hours I've only seen issues with the frame writing every 20 minutes, when the full and second trend frames happen to be written at the same time.  Running overnight to gather more statistics.

Tried to implement AGC on FE. Had some trouble bringing the code into the correct form. It looks okay now. However, this agc code as well as idenntity code (input = output) doesnt seem to build on the c1lsc FE. Have not tried too many debugging steps yet, will come and check the problem tomorrow. 

-Varun

Hi!

I am Aakash Patil. I will be working at the 40m lab as a SURF student with Gautam Venugopalan on enclosures for seismometers to shield them from thermal and magnetic fluctuations. This week I will be working on the development of hardware for four probe measurement along with a constant current source. It will effectively help us in accurate temperature measurement throughout the development of enclosure.

I am re-starting work on the daqd upgrade again now.  Expect the daqd to be offline for most of the day.  I will report progress.

Barring objections, starting tomorrow morning, Jamie will be testing the new FB code. The IFO will not be available for other use while this is ongoing.