63% coupling efficiency into the new fiber collimator (Thorlabs XXXX) and the blue fiber.This should be sufficient for a beat measurement with the PSL laser.

I think the coupling efficiency is not too bad with having no mode matching lenses and no adjustable collimator lens.

252mW in front of the fiber

159 mW fiber output

Summary:

The electronics chain used to drive the three elements of the PI PZT on which a mirror is mounted with the intention of controlling the LO phase has been changed, to now use the Trek Mode603 power amplifier instead of the OMC high voltage driver. Attachment #1 shows the new configuration.

Details:

The text of Attachment #1 contains most of the details. The main requirement was to map the DAC output voltage range, to something appropriate for the Trek amplifier. The latter applies a 50V/V gain to the signal received on its input pin, and also provides a voltage monitor output which I hooked up to an ADC channel in c1ioo. The gain of the interfacing electronics was chosen to map the full output range of the DAC (-5 to +5 V for a single-ended receiving config in which one pin is always grounded) to 0-2.5 V at the input of the Trek amplifier, so that the effective high voltage drive range is 0-125 V. I don't know what the damage threshold is for the PI PZT, maybe we can go higher. The only recommendation given in the Trek manual is to not exceed +/-12 V on the input jack, so I have configured D2000396 to have a supply voltage of 11.5 V, so that in the event of electronics failure, we still don't exceed this number.

On the electronics bench, I tested the drive chain, and also measured the transfer function, see Attachment #2. Seems reasonable (the Trek amplifier was driving a 3uF capacitive load used to protect the SR785 measurement device from any high voltage, hence the roll-off). The gain of D2000396 was changed from 1/8 to 1/4 after I realized that the DAC full range is only +/- 5 V when the receiving device is single-ended at both input and output. Maybe the next iteration of this curcuit should have differential sending, to preserve the range.

Testing:

To test the chain, I used the single bounce beam from the ITM, and interfered it with the LO. Clear fringing due to the seismic motion of the ITM (and also LO phase noise) is visible. In this configuration, I drove the PZT mirror in the LO path at a higher frequency, hoping to see the phase modulation in the DCPD output. However, I saw no signal, even when driving the PZT with 50% of the full DAC range. The voltage monitor ADC channel is reporting that the voltage is faithfully being sent to the PZTs, and I measured the capacitance of the PZTs (looked okay), so not sure what is going on here. Needs more investigation.

Update Aug 30 5pm: Turns out the problem here was a flaky elbow connector I used to pipe the high voltage to the PI PZT, it had some kind of flaky contact in it which meant the HV wasn't actually making it to the PZT. I rectified this and was immediately able to see the signal. Played around with the dark fringe Michelson for a while, trying to lock the homodyne phase by generating a dither line, but had no success with a simple loop shape. Probably needs more tuning of the servo shape (some boosts, notches etc) and also the dither/demod settings themselves (frequency, amplitude, post mixer LPF etc). At least the setup can now be worked on interferometrically.

On Thursday, new huddle test data for the Wilcoxon 731A was aquired by Eric. 

The difference between this new data and the previous data, is:

1) We used three accelerometers instead of six this time around.

2) We used a foam box, and clamped cables on the experimental set up as shown in the previous elog, http://nodus.ligo.caltech.edu:8080/40m/11389

I have analyzed the new data. Here I present my results.

The following plot shows the ASD's for the three accelerometers raw outputs as well as their error signals computed using the three cornered hat method,

As before, I computed the mean for the output signals of the accelerometers above as well as their mean self noise to get the following plot

,

Now, below I compare the new results with the results that I got from the old data, 

Did the enclosure and cable clamping do much? Not really, according to the computed three hat results. Also, notice how much better, even if its a small improvement, we get from using six accelerometers and calculating their self noise by the six cornered hat method.

Now, I moved on to analyzing the same data with Wiener Filtering.

Here are again, the raw outputs, and the self noises of each individual accelerometer calculated using Wiener filtering,

The accelerometer in the Y direction is show a kind of funky signal at low frequncies. Why? Anyways, I calculated the mean of the above signals as I did for the three cornered hat method above to get the following, I also show the means of the signals computed with the old data using wiener filtering,

Is the enclosure really doing much? The Wiener filter that I applied to the huddle test old data gave me a much better, by an order of magnitude better self noise curve. Keep in mind that this was using SIX accelerometers, not THREE as we did this time. I want to REDO the huddle test for the WIlcoxon accelerometers using SIX accelerometers with the improved experimental setup to see what I get.

Finally, I compare the computed self noises above with what the manufacturer gives,

,

As I expected, the self noise using six accelerometers and Wiener filtering is the best I could work out. The three cornered hat method works out pretty well from 1 to 10 Hz, but the noise is just too much anywhere higher than 10 Hz. The enclosed, clamped, 3 accelerometer wiener filter result is an order of magnitude worse than the six accelerometer wiener filtered result, and two orders of magnitude worse than the three cornered hat method in the 1 to 10 Hz frequency band. 

As I stated, I think we must performed the huddle test with SIX accelerometers and see what kind of results we get.

After munching analytical models, simulations, measurements of photodiodes I think I got a better grasp of what we want from them, and how to get it. For instance I now know that we need a transimpedance of about 5000 V/A if we want them to be shot noise limited for ~mW of light power.

Adding 2-omega and f1/f2 notch filters complicates the issue, forcing to make trade-offs in the choice of the components (i.e., the Q of the notches)

Here's a better improved design of the 11Mhz PD.

 This should be better. It should also have larger resonance width.

How much is the width?

 The transfer function phase drops by 180 degrees in about 2MHz. Is that a good way to measure the width?

To measure the width of a resonance, the standard method is to state the center frequency and the Q. Use the definition of Q from the Wikipedia.

As far as how much phase is OK, you should use the method that we discussed - think about the full closed loop system and try to write down how many things are effected by there being a phase slope around the modulation frequency. You should be able to calculate how this effects the error signal, noise, the loop shape, etc. Then consider what this RFPD will be used for and come up with some requirements.

I have updated the vacuum checklist for in vacuum alignment.  Please take a look (https://wiki-40m.ligo.caltech.edu/vent/checklist) and see if I missed anything.  My goal was to make it incredibly step-by-step so there can be no mistakes.

 Here's a picture of where I am now inputting signals into the STACIS with the accelerometers (the orange and blue wires): 

I know this is the right point because I could see the geophone signal from these points . By inputting a swept sine signal into this point, I was able to take a transfer function of this first amplifier/filtering circuit board, which will be useful if I need to make my own filter for the STACIS:

I have unplugged the geophones and am inputting a signal from an accelerometer into this point. The accelerometers output a different signal than the geophones, so I am trying to modify the accelerometer signal to be closer to the geophone one. I've lowered the gain on all the pots for the z axis and put in several BNC attenuators to lower the accelerometer signal amplitude.

At the moment, using the accelerometers as feedback makes the platform vibration worse, which will hopefully be solved by some more attenuation or filtering of the accelerometer signal.

I forgot to elog about these ones, my bad... The new/updated laptops are giada, viviana and paola; paola is already in the lab, while giada and viviana are in the control room waiting for a new home. The Pool of Names Wiki page has already been updated to reflect the changes.

Be aware that there is now a KEPCO HV supply that is energized, sitting on the floor immediately adjacent to the OMC rack, east of the AP table. It is currently set to 100 V DC, and a PI PZT installed on the AP table has its 3 PZTs energized by said supply (via an OMC piezo driver). I will post pictures etc of the work from the last 10 days over the weekend.

I locked PRMI, and (after fixing the POP QPD situation, noted in elog 9249) took power spectra of all the REFL RFPDs.  It looks like the area above 500 Hz is pretty clean and flat for all the signals, so I'm going to use 560Hz, 562Hz, 564Hz, 566Hz and 568Hz for my 5 sensing matrix frequencies.

Also, I'm not sure what is going on with REFL11, but there's a weird dip between 630 Hz and 660 Hz in both I and Q.  I recentered this guy not too long ago (elog 9218), but it clearly needs some more looking-at.

 I worked today some more on the new Sensing Matrix situation.  I have added stuff to the CAL model, so that the sensing matrix elements come out calibrated to W/m, with phase in degrees.  The idea is that we can see time series of the calibrated lockin outputs, so that we have minimal post-processing to do, since these are things that will be interesting to look at live.

The first step is to go from I and Q to magnitude and phase.  Each "sensor" (ex. REFL55Q) is demodulated with a lockin part, which outputs sub I and Q channels (so, something like REFL55Q_I and REFL55Q_Q).  We are only interested in the _I component of the lockin.  But, REFL55I also has a _I and _Q.  Again, we only take the _I part.  Now, we have REFL55I_I and REFL55Q_I.  We call these the I and Q components of the sensors (this is exactly what we normally call them, but it can get confusing since the lockins also have _I and _Q before we discard the _Q part).  Now, we want to take these I and Q components, and transform them to a magnitude and phase. After we do that, we want to calibrate the magnitude to "Watts per meter" from "counts sensed per counts driven".  I also converted the phase to degrees, since that's the unit we usually use when talking about the sensing matrices. 

To go from the I and Q components to Mag and Phase, I wrote a little block of c-code, which is in /opt/rtcds/caltech/c1/userapps/release/isc/c1/src/MagPhaseFromIQ.c . Since we can't use the arctan function, I approximated it using equation 17 from Full Quadrant Approximations for the Arctangent Function [Tips and Tricks] from IEEE.  (I used x -> y/x in equation 17, so that I had a 2D situation).  I also have an "if / else if" cascade to determine what quadrant I'm in.  Since the formula in the paper is from [0,pi/2), I just needed to add pi, subtract the answer from pi, or negate the answer to get to the other quadrants.  Also, note that they are using a "normalized" arctan function, so equation 17 is really from [0,1), and you have to remember to multiply by pi/2 on your own.

To get from drive counts to drive meters, I put in an EPICS variable for the optic's actuation constant (ex, PRM's constant can be found in elog 8255).  Right now, we have to transfer the oscillation frequency from the oscillator part's _FREQ variable to a new EPICS variable, but Zach and Joe just today made a new oscillator part that makes it easier to access the frequency and amplitude of the drive within the front end.  See LLO aLog 9139 for details on this new part.  I had trouble compiling with their new part, but once I get that figured out, I won't need to do this transfer of information.  Anyhow, the drive calibration is (optic actuation constant)/[(drive frequency)^2]. 

Then the total calibration of the magnitude is Mag in cts/m = 2 * mag / [(drive amplitude) * (drive calibration)] .  The factor of 2 comes from the fact that the lockin output is a factor of 2 smaller than the true sensing matrix element.  The lower case "mag" in the formula is the output of the c-code. 

After this, there is yet another EPICS variable, to hold the calibration for the photodiode, to get from counts sensed to Watts of power at the actual port.  By "actual port", I mean the true IFO port, taking into account any optical elements between the port and the photodiode, like beam splitters and dumps, or loss from the imperfect reverse isolation of the input Faraday.

The code all compiles and runs fine, although I haven't done any explicit testing yet.

Still to-do for Sensing Matrix:

* Find all of the numbers for all of the EPICS variables.  In particular, I need to get the ratio of the power hitting each photodiode to the power at that port. 

* Write a script to do a burt-restore with all the correct settings, and turn on the dither lines.

* Put the lowpass filters back in the demodulators, now that they have new (shorter) names.

* Try it, and compare with the optickle model, and previous measurements.

* Copy Anamaria's script to look at the error statistics for my measurements.

I have modified the Sensing Matrix I,Q to Mag, Phase library part in the new sensing matrix system.

I had forgotten that in the c-code, I convert from radians to degrees, and so was doing the conversion again in the model.  As it turns out, this gives you a nonsense number.  I removed the multiplication by 180/pi in the model, and just use the output of the c-code, which is already in degrees.

I also put in some "choice" blocks just before the divisions in the calibration section of this library part.  If it's about to divide by zero, divide by one instead.

The last modification so far today was adding the _PHASE_DEG and _MAG_WPERM (watts per meter) channels to a DAQ channels block, so that they are saved.

The RCG was very unhappy with me having 2 channels, with no data rate after them (doing this is supposed to imply that both should be saved at the default data rate), however after I put in "2048", it was happy.  The symptom was a little tricky:  The channel names in Dataviewer showed up red, even though the model compiles and runs.  An indicator that you have a problem is a note in the model's "GDS" screen (the details screen that you can click to from the CDS front end overview screen).  The channel name is "C1:FEC-50_MSGDAQ" (where the number 50 is specific to the c1cal model).  After restarting the model, but before restarting the framebuilder's daqd process, this channel said "Error reading DAQ file!", rather than the date and time of the last successful read.   At this point, before restarting the daqd process on the framebuilder, all of the fb statuses are green and good.  However, after restarting the daqd process on the framebuilder, I got status "0x2000".  Anyhow, after trying many different things, I determined that I could have 1 channel, without a specified rate, but if I wanted more than one channel, I needed to specify the rate for both.

After finishing up working on the models for today, I made corresponding screens.  

The new Sensing Matrix (and lockin) overview screen is accessible from the sitemap:  LSC -> Sensing Matrix. 

From there, you have the oscillators, input matrices (one per degree of freedom), output matrix, and the lockin modules themselves.  You can either look at several PDs for one degree of freedom (ex. there is a screen for all the AS RFPDs, demodulated for the DARM oscillation), or all the degrees of freedom for a single PD (ex. how are all the degrees of freedom seen in AS55Q?).  The LSC screen has been updated to match - now you see 5 oscillator readbacks, and a larger output matrix.  There is a button for the Sensing Matrix overview screen, and if you click on the cartoons of the oscillators, it'll take you to the oscillators screen.

Still to do:

* Decide what 5 frequencies to use for excitation.

* Put the bandpass and lowpass filters into the lockin modules.

* Put matching notch filters into each LSC servo.

* Re-write the sensing matrix scripts.

* Put a little more stuff into the front end so that we get total mag and phase of the sensing matrix element, not just uncalibrated lockin outputs.

 I worked on some of these "to-do" things today for the new sensing matrix setup.  I chose several frequencies around 90 Hz for my measurements.  This was an area (while PRMI was locked with REFL 165 I&Q, and all 4 REFL PDs had their whitening on) there was a pretty wide clean space in the noise spectrum.

I put bandpass filters into the _SIG banks of the lockin modules, and lowpass filters into the _I banks.  However, when I loaded the new filter coefficients, it looks like not all of them are showing up in the screens.  I'm a little confused as to why.  They are still there if I close and re-open Foton, so I think I really put them in.

Also, I don't think that I'm successfully getting any signal from the LSC model into the new lockin modules on the CAL model.  I'm not sure if this is to do with the fact that I added 32 more IPC connections the other day.  I've emailed Jamie to ask whether or not we may have hit some limit.

I also tried testing out a small bit of c-code for the calibration of the lockin outputs.  It seems as though I cannot do an arctangent in the front end.  When I compile the c1tst model, and start it up, if I have an "atan2" in the code, it tells me "No Sync".  However, if I remove that line of c-code, the model compiles fine (which it did in the case with the arctan), and the model runs just fine (which it doesn't with the arctan).  My backup plan is to include a Taylor expansion for the arctangent in some c-code.

  I think that we always drive above the UGF for sensing matrix measurements since we like to put notches in the servo. In principle, we could drive within the control band and then take out the effect by measuring the control signal and undoing the gain in the digital filters. But that seems pretty complicated for any MIMO system.

 Hmmmm, yup.  I forgot to pay attention to what the UGFs of our LSC loops are when I was picking a low-noise region.  Since they're (currently, at least) around 100Hz, I want to find a frequency in the few hundred Hz region.  Masayuki has the IFO right now for ALS diagnostics, so I'll pick new frequencies later.   If we decide to omit the bandpass filters, it's even easier to change frequencies on the fly (although we'll always still have to make the servo notch filters match).

After staring and thinking, I remembered that there is a limit to the number of characters that a channel name can have.  So, I removed the "_LOCKIN" part of the names, and recompiled, and everything seems to work.  I modified the screens that I had made, and they show all the appropriate things now.  

The symptoms were that the numbers in the filter banks (for example, INMON) were white with the usual black background.  The numbers are supposed to be green with a black background.  After I recompiled, all the numbers were green.

This also means I need to re-put in the low pass filters. 

Summary:

I implemented most of the things outlined in my previous elog. Implementing the a la mode solution after including all lenses, I managed to achieve >90% mode-matching into the fiber. Power monitor PD has not been re-installed yet, neither has the bracket I removed. The polarization monitoring setup on the PSL table has now been hooked up to the EX fiber, let's see how it does overnight. All quoted power measurements in this elog were made with the Ophir power meter (filter off).

Details:  

Attachment #1 shows the implemented MM solution. I did not include the PBS substrate in the calculation, maybe that will help a little.

Attachment #2 shows the new layout. The beam is a little low on the PBS and HWP - I will swap these out to mounts with slightly lower height, that should improve the situation a little. There is no evidence of clipping, and the beam clears all edges by at least 3 beam diameters.

Attachments #3 and #4 show the EX fiber before and after cleaning respectively. Seems like the cleaning was successful.

Attachment #5 shows the beam incident on the coupler with on an IR card. This beam only goes through a QWP, lens, BS and 45 degree steering mirror, so I'm not sure what's responsible for the large halo around the main beam. There is significant power in the halo too - I measured 25mW right before the coupler, but if I use an iris to try and cut off the halo, the power is measured to be ~19mW.

Alignment Procedure:

• Connect spare fiber such that I can monitor coupled power (minus fiber losses and joint loss) at EX table.
• Use Fluke fault analyzer to align input and collimator modes coarsely.
• Monitored coupled power continuously using Fiber Power Meter (although MM calculations were made with Ophir, this was more convenient for "Live" viewing).
• Tweaked one available steering mirror and K6XS axes to maximize coupled power. 
• Tweaked lens positions slightly to see if significant improvement could be made.
• After optimizing, I measured 17.1mW coming out of the EX fiber at the PSL table. As mentioned earlier, the input power is tricky to measure given the large amount of junk light around the main mode. But I measured 18.6 mW after the iris. So this is ~95%. In any case, safe to say that we are waaaay better than the previous situation of 380uW out of 1.9mW. 
• Added PBS and HWP to cut the incident power to 1.6mW. I measured 1.2mW on the PSL table. Probably adding the PBS screwed up the MM a bit, to be tweaked tomorrow. 
• I had moved the Green shutter a bit during this work - as a result, the Green REFL was not making it back to the REFL PD. I remedied this, and EX Green TEM00 mode was locked to the arm. GTRX of ~0.4 was recovered, which is around the number I'm used to seeing.

Here is a first look at the overnight stability. For the temperature, I used the calibration I found in the old psl database file, seems to give sensible results. It's only 15 hours of data plotted, so we don't see the full 24 hour temperature swing, but I think it is safe to say that for the EX fiber, the dominant cause of the "waveplate effect" is not in fact temperature drift. The polarization extinction is still better than 10dB in the entire period of observation though... I'm going to push ahead with a beat spectrum measurement, though there is room for improvement in the input coupling alignment to fiber special axes.

The apparent increase in these plots towards the end of the 15 hour period is because the lights on the PSL table were switched on.

Annoyingly, it seems like the PSL NPRO channels (which I have hijacked to do this test) do not have minute trend data directly accessible from NDS2. Not sure whether this is an NDS2 problem, or something missing in the way the channels are setup with Acromag. Probably the former, as I am able to generate minute trend plots with dataviewer. I forget whether this is the same as the infamous minute trend problem. Second trend data is available though, and is what I used to make these plots...

 Yesterday, I made new mounts for microphones.

I glued a microphone on a pedestal. The cables are attached loosely so that its tension does not make any noise.
At the bottom of the mount, I attached the surgical tube forming a ring by double-side tape so that it damps the seismic vibration.

I made 6 mounts and these are all on the AS table now.
I took some data of XARM signal controlled by AS.

My plan is to find/set an upper limit on acoustic coupling noise in AS signal.
The acoustic noise can be estimated by the Wiener filter, but it is not accurate because it may see residual correlation between AS and microphone signals that should be 0 when the data is long enough.
I will find/set an upper limit by the analysis based on Neuman-Pearson criterion, that is analog of a stochastic GW background search.
If I can find the acoustic coupling noise should be below the shot noise, I am happy. If not, some improvements may be needed someday.

Since Den wasn't able to fix c1sus (make it talk to the framebuilder) before he left a few hours ago, I decided to do some housekeeping rather than actual locking. 

I wrote new save / misalign / restore scripts for all of the suspended optics on the C1IFO_ALIGN screen.  Adding save / restore versions for the mode cleaner optics should be quick and easy.  Now when you use the ! button for each optic, it points you to the new scripts.  I still have the burt capabilities there, but the restore script has the burt-restore line commented out.

Functionality:

SAVE:  burt-save the PIT_COMM and YAW_COMM values, as well as write those values and the date to a text file.

MISALIGN:  Turn off oplevs, move 100 steps of 0.01 in the "+" direction.

RESTORE: Move ~100 steps toward the saved value, until you're within 0.001 of the saved value (step size is "saved val" minus "current val" divided by 100).  Then just write the saved value to the slider (otherwise if the slider were touched between the last "save" and the restore, we might not be able to step precisely to the value we want). Turn oplevs back on.

Scripts are in the same place the old ones used to live:  ...../caltech/c1/medm/c1ifo/cmd/   New scripts are C1IFO_OPTIC(save/restore/misalign)_soft.cmd

I'm checking this one off of the to-do list.

Good things:  (a) I remembered / re-learned / just plain learned a lot about scripting.  (b) the optics are now walked slowly over to their misaligned state, and slowly walked back.  The past regime had the optics suddenly kicked over by a lot, sometimes enough to trip / come close to tripping watchdogs, which was never good.

Bad things: it took a long time.  Now it's bedtime.

I have made a new model for the endtable PZT servo, and have put it in c1iscex. Model name is c1asx. Yesterday, Koji helped me start the model up. The model seems to be running fine now (there were some problems initially, I will post a more detailed elog about this in a bit) but some channels, which are computer generated, don't seem to exist (they show up as white blocks on the MEDM GDS_TP screen). I am attaching a screenshot of the said screen and the names of the channels. More detailed elog about what was done in making the model to follow.

Channel Names:

C1:DAQ-DC0_C1ASX_STATUS (this is the channel name for the two leftmost white blocks)

C1:DAQ_DC0_C1ASX_CRC_CPS

C1:DAQ-DC0_C1ASX_CRC_SUM

I don't know what's going on here (why the channels are white), and I don't yet have a suggestion of where to look to fix it but...

Is there a reason that you're making a new model for this?  You could just use and existing model at c1iscex, like the c1scx, and put your stuff in a top-names block.  Then you wouldn't have to worry about all of the issues with adding and integrating a new model.

I have made some minor changes to the model, made all the MEDM screens, and linked monitors on these to the appropriate channels. I have borrowed heavily from the C1ASS MEDM screens (particularly for the small filter modules-it was convenient to just copy and paste an existing module, and edit the channel names using EMACS/GEDIT), and have edited these to suit the needs of this servo. Some features:

• The feedback signal (only the output of the servo to the PZTs, plus any contribution from the on-screen sliders, and not including the LO output) is monitored with both a slow (using CDS_EPICS_OUTPUT block from the CDS_PARTS library) and fast channel (using Test Point from the same library). The idea is that it would be useful to know the output to the PZTs such that if coarse adjustment ever needs to be done at the endtable, the PZTs can be restored to the middle of its operating range by means of the sliders.
• Sliders are incorporated into the master screen for adjusting the output to the PZTs. There are text-input fields below the sliders as well, which control the same channel.
• I have removed the 4 remaining excitation points to the DAC set up in C1SCX, and have relocated them to channels 12-15 of the DAC in C1ASX.

I think I am now ready to take some measurements and try and optimize this servo. There is no green transmission at the PSL table at the moment, so not much can be done, though the first step would be to take the power spectrum of the error signal, which would help me decide the appropriate frequencies for the LOs. I would then have to add the appropriate filters to the model. The last, and most difficult step, would be the measurement of the output matrix, though Koji has given me some ideas about how this measurement can be done. I also have a template script ready, though I will only finalise this after optimising the servo and running it a couple of times manually.

Attached are screenshots of the MEDM screens.

Koji just fixed this.

It seems that the new model's channels were not automatically added to the master file in the framebuilder (/opt/rtcds/caltech/c1/target/master). Adding the following two lines to the master file fixed the problem;

/opt/rtcds/caltech/c1/chans/daq/C1ASX.ini

/opt/rtcds/caltech/c1/target/gds/param/tpchn_c1asx.par

The box is now green. It looks like C1ASX.ini is created automatically in /opt/rtcds/caltech/c1/chans but the master file needs to be manually edited. The channels are now showing up on dataviewer etc. I have updated the information on the wiki page.

 These are roughly the steps I followed in setting up the new model for the endtable PZT servo - C1ASX.

Simulink model:

I made a SIMULINK model of the servo, using MATLAB R2013a. The path to the model is /opt/rtcds/caltech/c1/userapps/release/isc/c1/models/c1asx.mdl. I am listing the parameters set on the CDS_PARAMETERS block:

• host = c1iscex
• site = c1
• rate = 16k
• dcuid = 44 (which I chose after making sure that this dcuid was not used on this list which was last updated end Feb 2013)
• specific_cpu = 5 (again chosen after checking the available CPUs in the above list).
• adc_Slave = 1
• shmem_daq = 1
• no_rfm_dma = 1
• biquad = 1

Making, Compiling and Installing the Model:

After saving the model, I ssh-ed into c1iscex and ran the following commands:

rtcds make c1asx - this gave me a whole bunch of errors initially, which I tracked down to a naming problem in some of the from and goto flags: there should not be any spaces.

rtcds install c1asx 

rtcds start c1asx - this gave me an error which said something like 'can't start/stop model.' Koji pointed out that given that a new model is being started, there is an additional step involved, which is to add the model name to the rtsystab file (this is located at /diskless/root/etc/rtsystab on framebuilder, and is mirrored in the various computers. It would be advisable to make sure that the changes are mirrored in the corresponding file on the computer in which the new model is being installed). 

After adding the model name to the rtsystab file, I tried running rtcds start c1asx again. This time, no errors were output, but the model was not up and running as verified by looking at the C1:ASX_GDS_TP medm screen.

 Debugging 

Koji suggested making a simple model (1 CDS parameters block, 1 ADC block and 2 filter modules, appropriately terminated) and see if that starts up, which it did. I then tried adding my servo minus the DAC block and recompiled and restarted the model. This too worked fine. I figured that the next logical step would be to add the DAC block to the model, and restart the model. But when I tried this, c1iscex crashed .

Jenne helped in restoring things to a working state (we reverted the c1asx model to just 2 filter modules, and went to the X-end and restarted the computer. This did not work the first time so I went back in and restarted it again, at which point we were able to ssh into c1iscex again and restart the four models running on it).

Since Manasa and Koji were working on getting things set up for the pumpdown,I did not try anything again till later in the evening, when Koji helped in debugging the problem further. In the meantime, at Jenne' suggestion, I made the model once again in MATLAB R2010b. In the evening, when I tried restarting the model, Koji suggested that the DAC channels in c1asx may be used by other models, at which point I realised I had set up excitation points on channels 8 through 15 of the DAC in c1scx (detailed here) in order to test the hardware at 1X9. I removed the excitation points from channels 8-11 of the DAC block in c1scx (these are the ones used in c1asx), and recompiled and restarted c1asx (using the above sequence of commands). I then tried recompiling and starting c1asx once more, and this time, it worked . At least, the GDS_TP screen suggests that the model is running alright, except for the fact that some computer generated channels seem to be missing. This problem is unresolved for now, and probably has something to do with the fact that C1ASX channels do not appear in Dataviewer.

I do not think this has to do with restarting framebuilder (I did the usual telnel fb 8088 followed by shutdown). In any case, I have added the new model to the CDS_FE_STATUS screen, and will continue to debug the same. I have also got a template medm screen (work in progress) which I will elog about soon as I get it done.

Note to self: There are 4 more excitation channels still hooked up to the DAC (channels 12-15) in the c1scx model. I plan to remove these and put them in c1asx.

Using all of the latest parameters that I can find, I have re-modeled the 40m sensing matrix.  Also, I have it output the data in a format that can be used by the same plotting function as the measured sensing matrix, so they are nice and easy to compare.

The newly modeled 40m sensing matrix:

To compare, here is the measured sensing matrix from elog 8644:

Notice that (a) the units are different, so don't focus too much on the amplitudes of the lines, and (b) all of the measured and modeled matrix elements are pretty similar, except for the REFL11.  REFL11 (top right in model plot, top center in measured plot) looks like it's flipped, as well as rotated.  The new model doesn't match up too well with the Kiwamu/Koji models (which matched eachother okay), but I like that the new model matches the measurements fairly well.  The Koji sensing matrix: on the 40m wiki

EDIT: I have replaced the modelled plot with a new version.  The data and numbers are the same, but I have switched the labels on the individual radar plots, and forced them to be in the same order as they are in the measured plot.

I'd repeat the measurement for REFL11. The PRC arrow has some big error bar on it, and maybe the true error is even bigger.

Also, please make the placement of the plots the same for modeled and measured so it's easy to compare.

I put in a new version of the modelled plot.  I figured out a different way to keep things generic so the same script can be used for other sites, but writes the names in the same format as the measured matrix, so the correct order is preserved.

The REFL11 measurement is consistent with the one in elog 8648 (data taken a few days earlier), within the error bars.  My goal for tonight is to hopefully get the POP path back in order, so that I can lock the PRMI again, and can measure again if I want.

The error bars for each sensor are only taken once (with no drive, so it's the noise in the "dark" sensor).  I take 6 "dark" measurements for each sensor, and get the stdev.  Then I use that and propagate it through for each measured sensing matrix element.  So, the PRCL and MICH error bars for REFL11 were created from the same standard deviation, and propagated in the same way, but the values plugged into the partial derivative of the function were different for PRCL and MICH. 

(wikipedia - propagation of uncertainties)

Also, to answer an emailed question via the elog, the "0 degree" axis of the plots is the 0 demod phase axis, which corresponds to the I output of the demod boards (the I input to the RFPDs, before the phase rotation).  The "I" axis that I've drawn is the current demodulation phase that we have, which corresponds to the I_ERR output of the RFPDs after the phase rotation, which is the PD_I signal that goes into the LSC input matrix.  I draw this to help us see if our current demod phase is well tuned or not.

Yes, the MICH and PRCL signals are not at all orthogonal in the REFL33 sensor.  I think this is because our modulation frequency was chosen to be good in the case of the full DRFPMI IFO, not the corner IFO cavities.  As I calculated in elog 8538, the ideal frequency for the PRMI is 18kHz larger than our current modulation frequency. 

For the plots below, note that 11.066134 MHz is our current actual modulation frequency, and 11.0843 MHz is my calculated ideal modulation freq. 

Model, using our current modulation frequency, and the designed PRCL cavity length (same as elog earlier today):

Model, using the "ideal" PRMI modulation freq, and the PRCL cavity length used in elog 8538, where I calculated that number (a few cm different than the design PRCL length):

You can see that if we could use a better frequency, we would get much, much better signal separation.  Since our modulation frequency choice is related to our vacuum envelope constraints (we can't make the arms of a length that will have the sidebands exactly antiresonant when the arms are locked on the carrier), I hope that this will not be a significant issue in aLIGO. 

 This is nice - how about figuring out how to plot the measurement and model on the same plot? I guess we need to figure out how to go from counts to Watts.

I haven't done a units conversion for the measured vs. modelled plot,  but at least we can compare the separation between the different degree of freedom signals.  Figuring out why the REFL11 measurement and models are so different is still high on my to-do list.  But at least the measurements that were taken last month are consistent with one another. EDIT:  The separation angles match up pretty well between the 2 sets of measurements, but the overall rotation isn't really consistent.  I do not believe that the phase rotation values that we're using online changed between the measurements, so the I&Q lines should be the same for both seets of measurements....however, I did not write down the phase rotation values at the time of the first measurement, so there's a chance that they were different.  Also, something that I need to monitor is the coherence of my measurement, to make sure I'm really driving and measuring something.

2 measurements, with overall rotation arbitrarily rotated to make MICH lines match up:

Same 2 measurements, without the arbitrary overall rotation:

Measurement vs. Model, with the *modelled* phase arbitrarily rotated:

[Kiwamu / Katrin]

On Wednesday, the green light was locked to the Y arm cavity.

Modulation frequency was changed from 279kHz to 178875Hz. The amplitude was changed from 10Vpp to 0.01Vpp to achieve a modulation index of 0.38. The modulation frequency was changed to minimize AM. With the new modulation frequency the laser light could still locked to the cavity.

The signal of the LO and the photodiode are multiplied by a ZAD-8 mini circuit mixer (Level 7). This mixer requires LO input is +7dBm = 1.4Vpp. Thus we put a 36dB attenuator between the LO and the PZT at the laser. PDH error signal shows lots of peaks that are most likely higher order sidebands. Thus, the next step is to work on the low-pass filter. However the SNR of the error signal has improved with the new modulation frequency. With the old mod. frequency the PDH signal was 4mVpp and the noise floor was 2mVpp.

Phase between the photodiode signal and LO is shifted by about 10 degrees. Step two is to work on a phase shifter.

A new webview of the LSP model is available at:

https://nodus.ligo.caltech.edu:30889/FE/lsp_slwebview_files/

This model include a couple example noise generators as well as the new Matrix of Filter banks (5 inputs x 15 outputs = 75 Filters!).  The attached png shows where these parts can be found in the CDS_PARTS library.  I'm still working on the automatic generation of the matrix and filter bank medm screens for this part.  The plan is to have a matrix screen similar to current ones, except that the value entry points to the gain setting of the associated filter.  In addition, underneath each value, there will be a link to the full filter bank screen.  Ideally, I'd like to have the filter adl files located in a sub-directory of the system, to keep clutter down.

I've cut and past the new Foton file generated by the LSP model below.  The first number following the MTRX is the input the filter is taking data from and the second number is the output its pushing data to.  This means for the script parsing Valera's transfer functions, I need to input which channel corresponds to which number, such as DARM = 0, MICH = 1, etc.  So the next step is to write this script and populate the filter banks in this file.

# FILTERS FOR ONLINE SYSTEM
#
# Computer generated file: DO NOT EDIT
#
# MODULES DOF2PD_AS11I DOF2PD_AS11Q DOF2PD_AS55I DOF2PD_AS55Q
# MODULES DOF2PD_ASDC DOF2PD_POP11I DOF2PD_POP11Q DOF2PD_POP55I
# MODULES DOF2PD_POP55Q DOF2PD_POPDC DOF2PD_REFL11I DOF2PD_REFL11Q
# MODULES DOF2PD_REFL55I DOF2PD_REFL55Q DOF2PD_REFLDC Mirror2DOF_f2x1
# MODULES Mirror2DOF_f2x2 Mirror2DOF_f2x3 Mirror2DOF_f2x4 Mirror2DOF_f2x5
# MODULES Mirror2DOF_f2x6 Mirror2DOF_f2x7 DOF2PD_MTRX_0_0 DOF2PD_MTRX_0_1
# MODULES DOF2PD_MTRX_0_2 DOF2PD_MTRX_0_3 DOF2PD_MTRX_0_4 DOF2PD_MTRX_0_5
# MODULES DOF2PD_MTRX_0_6 DOF2PD_MTRX_0_7 DOF2PD_MTRX_0_8 DOF2PD_MTRX_0_9
# MODULES DOF2PD_MTRX_0_10 DOF2PD_MTRX_0_11 DOF2PD_MTRX_0_12 DOF2PD_MTRX_0_13
# MODULES DOF2PD_MTRX_0_14 DOF2PD_MTRX_1_0 DOF2PD_MTRX_1_1 DOF2PD_MTRX_1_2
# MODULES DOF2PD_MTRX_1_3 DOF2PD_MTRX_1_4 DOF2PD_MTRX_1_5 DOF2PD_MTRX_1_6
# MODULES DOF2PD_MTRX_1_7 DOF2PD_MTRX_1_8 DOF2PD_MTRX_1_9 DOF2PD_MTRX_1_10
# MODULES DOF2PD_MTRX_1_11 DOF2PD_MTRX_1_12 DOF2PD_MTRX_1_13 DOF2PD_MTRX_1_14
# MODULES DOF2PD_MTRX_2_0 DOF2PD_MTRX_2_1 DOF2PD_MTRX_2_2 DOF2PD_MTRX_2_3
# MODULES DOF2PD_MTRX_2_4 DOF2PD_MTRX_2_5 DOF2PD_MTRX_2_6 DOF2PD_MTRX_2_7
# MODULES DOF2PD_MTRX_2_8 DOF2PD_MTRX_2_9 DOF2PD_MTRX_2_10 DOF2PD_MTRX_2_11
# MODULES DOF2PD_MTRX_2_12 DOF2PD_MTRX_2_13 DOF2PD_MTRX_2_14 DOF2PD_MTRX_3_0
# MODULES DOF2PD_MTRX_3_1 DOF2PD_MTRX_3_2 DOF2PD_MTRX_3_3 DOF2PD_MTRX_3_4
# MODULES DOF2PD_MTRX_3_5 DOF2PD_MTRX_3_6 DOF2PD_MTRX_3_7 DOF2PD_MTRX_3_8
# MODULES DOF2PD_MTRX_3_9 DOF2PD_MTRX_3_10 DOF2PD_MTRX_3_11 DOF2PD_MTRX_3_12
# MODULES DOF2PD_MTRX_3_13 DOF2PD_MTRX_3_14 DOF2PD_MTRX_4_0 DOF2PD_MTRX_4_1
# MODULES DOF2PD_MTRX_4_2 DOF2PD_MTRX_4_3 DOF2PD_MTRX_4_4 DOF2PD_MTRX_4_5
# MODULES DOF2PD_MTRX_4_6 DOF2PD_MTRX_4_7 DOF2PD_MTRX_4_8 DOF2PD_MTRX_4_9
# MODULES DOF2PD_MTRX_4_10 DOF2PD_MTRX_4_11 DOF2PD_MTRX_4_12 DOF2PD_MTRX_4_13
# MODULES DOF2PD_MTRX_4_14  
# MODULES 

 I have redone the SPSR785 (spectrum measurement) and TFSR785 (TF measurement) commands in scripts/general/netgpibdata. This was mostly motivated by my frustration with typing out either a ton of command line arguments, or rooting around in the script itself; I'd rather just have a static file where I define the measurement, and can keep track of easier. 

They currently take one argument: a parameter file where all the measurement details are specified. (i.e. IP address, frequencies, etc.) There are a few template files in the same directory that they use as default. (Such as TFSR785template.yml)

If you call the functions with the option '--template', it will copy a template file into your working directory for you to modify as you wish. "SPSR785 -h" gives you some information as well (currently minimal, but I'll be adding more)

In the parameter file, you can also ask for the data to be plotted (and saved as pdf) when the measurement is finished. In SPSR785, and soon TFSR785, you can specify a directory where the script will look for reference traces to plot along with the results, presuming they were taken with the same measurement parameters and have the same filename stem. 

I've tested both on Pianosa, and they seem to work as expected. 

Todo:

• Add support for modifying some parameters at the command line 
• Extend to the Agilent analyzer
• Maybe the analyzer settings written to the output file should be verified by GPIB query, instead of writing out the intended settings. (I've never seen them go wrong, though)
• Make sure that the analyzer has PSD units off when taking a TF. (Thought I could use resetSR785 for this, but there's some funkiness happening with that script currently.)
• Possibly unify into one script that sees what kind of analyzer you're requesting, and then passes of to the device/measurement type specific script, so we don't have to remember many commands. 

Comments, criticism, and requests are very welcome. 

(P.S. all the random measurement files and plots that were in netgpibdata are now in netgpibdata/junk. I feel like this isn't really a good place to be keeping data. Old versions of the scripts I changed are in netgpibdata/oldScripts)

Does netgpibdata/TFSR785 work at the 40m currently? I rsynced the netgpibdata directory to LHO this morning to do some measurements, but I had to modify a few lines in order to get it to call the SR785 functions properly. My version is attached.

It does appear to work here. However, I've since supplanted TFSR785 and SPSR785 with SRmeasure, which has some simpler command line options for directly downloading a manually configured measurement. I've also set up a git repository for the gpib scripts I've done at https://github.com/e-q/netgpibdata, which could be easier than grabbing the whole 40m directory. 

• 10m PM1064 cable was installed. I tried a double shielding approach (photos tmrw here), but I suspect the real weak point is where the fiber is plugged into the collimator - it's hard to imagine we can stabilize this sort of arrangement to better than 100um absolute length over long periods of time, I'd think thermal/mechanical strains in the fiber will modulate the length by ~mm (?). Anyways, let's see what the heterodyne measurement tells us.
• This work required (i) realignment at the input coupler and (ii) change of position of mode matching lenses in the LO path on the AS table to see any interference with the IFO beam. This indicates something was seriously wrong with the old patch cable, as the collimator should set the mode. The MFD of the two fibers may have been different, but I don't know if that alone can account for it.
• As of now, I have fringes between the ITM single bounce and the LO, but the fringe pk-pk is only 10% of the theoretical pk-pk based on DC values of the LO and AS beams. So the mode matching can be improved significantly (I preivously had ~60%).

To be continued tomorrow. I think it's a good idea to let the newly installed fiber relax into some sort of stable configuration overnight.

Created a new medm screen C1ALS_FOL_PID.adl for FOL PID loop control in /medm/als/master/

This is not currently linked to the sitemap screen.

After lots of trial and error, and a little inspiration from Koji, I have written a new script that will run when you select "update snapshot" in the yellow ! button on any MEDM screen. 

Right now, it's only live for the OAF_OVERVIEW screen.  View snapshot and view prev snapshot also work. 

Next on the list is to make a script that will create the yellow buttons for each screen, so I don't have to type millions of things in by hand.

The script lives in:  /cvs/cds/rtcds/caltech/c1/scripts/MEDMsnapshots, and it's called....wait for it....... "updatesnap".

I just put a script in the /cvs/cds/caltech/scripts/general/netgpibdata/ directory to control the network analyzer called AG4395A_Run.py .   A section has been added to the wiki with the other GPIB script sections (http://lhocds.ligo-wa.caltech.edu:8000/40m/netgpib_package#AG4395A_Run.py)

I took data for the 2 NPRO PLL using the script I wrote for the AG4395, but it is very noisy above about 1 MHz.  I assume this is something to do with the script (since I am fairly confident we don't have 600 dB response in the PZT), so I will go in tomorrow to more carefully understand what is going on, I may need to include a bit more latency in the script to allow the NA to settle a bit more.  I am attaching the spectrum just to show the incredibly high noise level,