Hmmm. Indeed. This is just cutting off higher frequency stuff, but anything from other lower sidebands still gets through.  I should actually stick in the SXBP-100's, which will band pass from 87-117 MHz.  These have an insertion loss at 100 MHz of 1.64 dB. 

Jamie ordered 2 of these, so I can put one in each of AS110 and POP110. 

I measured the phase split between the I and Q signals of my AS110 board.  To do so, I plugged the board into an empty slot next to the PD DC readout / whitening board in the LSC rack.  I borrowed the POP110 local oscillator, and used a Marconi to generate a "PD input".  (I'm roughly following what Suresh did in elog 4736).  Our 11MHz is currently 11.066134MHz, so I had the Marconi going at 110.662340 MHz (1kHz from 10*11MHz), and I had the Marconi source at -13dBm.  

I took a transfer function using the SR785 between the I and Q outs of the AS110 demod board, and got a magnitude misbalance of 0.809 dB, and a phase split of 110.5 degrees.  This isn't so close to 90 degrees, but this may be a problem with the splitter that we're using, as Suresh detailed in elog 4755.  In that elog, he measured a phase split of POP110 of 105 degrees, unless the power going into the splitter was pretty high.  As with POP110, since I expect that we'll usually only look at one channel (I, for instance), this isn't such a big deal for AS110. 

I have left, for now, the board in the empty slot.  It looks like (I'm going to go check) there are 3 open channels on the whitening board that has the PD DC signals.  So, the only thing left to figure out is how we want to get some local oscillator action for this new board.

EDIT: Yes, those channels are available.  Right now (as a remnant from testing the whitening filters waaaay back in the day) they are called C1:LSC-PDXXX I, Q, DC.  I'll use 2 of those for the AS110 I and Q. 

As I see it, we have a few options for getting the 110 MHz LO to both the POP110 and AS110 demod boards.  

The current situation is described by Kiwamu in elog 5746.  The 55 MHz signal comes into the box, and is split 4 ways, with each path having 19.7 dBm.  One of these 4 is for 110.  It has a 2dB attenuator (giving us ~17.7 dBm), and then it goes to an MK-2 frequency multiplier.  I'm a little lost on why we're giving the MK-2 17 dBm, since it says that it can handle an input power between 1 - 15 dBm.  It has ~16 dB conversion loss, so the 110 output of the distribution board has (according to the drawing) 1.9 dBm.  The demod boards have a 10 dB attenuator as the first element on the LO path, so we're giving the ERA-5 -8 dBm. 

We can either amplify the 110 leaving the distribution box, split it, and then attenuate it to the appropriate level for the demod boards, or we can change the attenuators on the POP110 and AS110 demod boards. 

Since we seem to be over driving the 2x frequency multiplier, I think I should change the 2dB attenuator to a 5dB attenuator, so we're giving the 2x multiplier ~15 dBm.  The conversion loss of ~16 dB means we'll have -1 dBm of 110 MHz.  I want to amplify that by ~10 dB, to give 9 dBm.  Attenuate by 5 dB to get to 4 dBm, then split into 2, giving me 2 110 MHz spigots, each of ~1 dBm.  Since the demod boards expect between 0-2 dBm for the LO's, this should be just fine.

Thoughts, before I start scrounging parts, and pulling the RF distribution box?

svn status update. asx, als and ioo were found not committed. Not sure about who modified ioo last after Jenne.

//edit Manasa - edited the/ elog instead of replying //

[Rana, Jenne]

We did lots of poking around with the DRMI tonight.  I should elog more in the morning, but the most important points are:

Locking settings same as elog 9068, except PRCL gain changed to 0.035, and the FMs that are triggered.  PRCL tonight had FM2,3,6 triggered.  MICH had FM1,2,3,7 triggered.  SRCL had FM1,2 triggered.  Engaging the MICH boosts helped make things more quiet, so that some of the SRC boosts could be enabled.  Still not as good of lock stretches as Koji got last Friday (elog 9060). 

REFL55 and REFL11 were still saturating (only during acquisition), after the optical path changes I did last week (elog 9043).  We reduced the REFL55 whitening slider from 15 dB to 6 dB (but forgot to compensate with digital gain), to keep the counts (as seen on DTT time series, binning off) to less than ~20,000 counts.  REFL11 is still saturating, and we're not sure why, since it's slider gain is 0 dB.  To be investigated.

I was prepping the ASS to be more conveniently put into a wrapper script, which could be called from the IFO Configure screen.  This involved adding PRCL to the burt .req and .snap files, as well as modifying the scripts a little bit to include PRCL as an option.  I ended up changing the script names from DITHER_Arm_ON.py and DITHER_Arm_OFF.py to DITHER_ASS_ON.py adn DITHER_ASS_OFF.py, since they are no longer restricted to being arms-only.  You must still provide an argument to the script, to tell it which degree of freedom you want to activate.  I also changed the save offsets scripts.  The way they were, the X and Y arms just had separate hard-coded scripts, with no convenient way to incorporate PRCL.  I merged them (including PRCL) into WRITE_ASS_OFFSETS.py, which you must now provide the DoF as an argument.  I tested these new scripts on all 3 of the DoFs, and made changes to the ASS screen, so it now calls only the new scripts.  It should now be easy to incorporate future ASS modifications.

Rana was in the middle of modifying the ASS model to include SRCL, and we also need to include MICH.  The ASS model is not compile-ready, so don't compile it!!  If you need to compile the ASS, please save what's there as a different name, and do an "svn up" to get the latest working version.

We suspected that there might be angular drive issues with the SRM (it was wiggling a lot). We checked the damping via step responses - all Qs were less than 10. Then we found that the INPUT button on the SRM PIT OL was OFF (why ???). After turning this back on it behaved better. We measured the loop shape and found that the UGF was 7 Hz; good. Need to work on some loop shaping for this guy. Its just 1/f out to 300 Hz right now. UGF should be made a little lower so that we can stably turn on the Bounce/Roll notches and a ~50 Hz low pass filter.

Most importantly, the F2A filters need to be measured and implemented. They are a few years old.

 The PMC was locked on an LG 10 mode (or something like it), for at least the last 8 hours.  I relocked it on the regular 00 mode, and it's fine now.  

Also, in CDS news, I did an mxstream restart (the RCG upgrade is supposed to make this not an issue anymore...), and did a "diag reset" afterwards, and all of the IPC errors except for one in the LSC model have gone away (OAF is still not running....on my to-do list, but not super high priority).

I have pulled the RF distribution box out of the rack, so I can look at it, and modify it to have 2 110 MHz spigots. I'm going to make the mods as in elog 9072.

Before I pulled the distribution box, I turned off the RF Generation Box, so don't be surprised that the MC will not lock.  I have terminated the cables that bring the 11 and 55 MHz signals from the generation box to the distribution box, so if someone does turn on the generation box, there won't be bad reflections.

To get the box out, in addition to unplugging all of the cables that go to the distribution box, I had to disconnect 2 of the ADC ribbon cables from the top row of RFPD demod / whitening / ADC boards, since they were in the way.  Everything is labeled, so it should be easy to put back together.

Note to Future Jenne:  Past Jenne put the screws needed for those ADC cables and to hold the box in the rack, in the plastic box that is on the floor in front of the LSC rack. 

Also, I measured the 110 MHz port before I pulled the board, so I would know what my "before" looked like.  I was using the 300MHz 'scope's measurement functions, so these are in volts, not dBm.  Amplitude = 1.33V, RMS = 456 mV, freq = 109.4-111.9 MHz

After scrounging for parts, and opening up the box, I have modified my proposal to the following:

Note that the freq multiplier is supposed to take, at maximum, 15 dBm.  The reason I put the 5 dB attenuator, then an amplifier, then another attenuator is that I don't know of / can't find easily a 10 dB amplifier with the usual case type on the MiniCircuits site.  (If anyone knows of one off the top of their head, that would be handy.  Then I'd remove the attenuator between the multiplier and the amplifier, and make the 10 dB attenuator a 5 dB.)

Anyhow, the ZFL-500HLN can only output 16 dBm of power, and I don't think I have space for another ZHL-2 (which can output up to 26 dBm) inside the box, so I put an attenuator before, as well as after, the amplifier. 

I think I have space inside the box for all the bits and pieces I'll need, although to do things correctly, I need to drill holes in the teflon mounting plate to mount the amplifier and splitter.

I also think that I have space on the front panel to put another isolated SMA feedthrough.

I have, on my desk, all the parts (except for mounting screws, and cables between things) to make these modifications to the distribution box. 

The RF distribution box is still on the bench, so again, don't be surprised that the MC doesn't lock.

I have completed my modifications as proposed in elog 9096, but I want to do a couple of quickie tests in the morning before I declare it ready for service.

 I have removed the 135 MHz low pass from my new AS110 demod board, but these SXBPs have different feet than the SCLFs, so I want to confirm with Koji or someone that I can solder them in the same way, before I get carried away and destroy anything.  I should be able to finish this up tomorrow, plug in the demod board and the distribution box, and try out AS110 triggering, etc, tomorrow night.

I have reinstalled the RF distribution box, as well put in the AS110 demod board.  I plugged everything back in, and turned it all on.

The switch on the distribution box may be starting to fail.  When I was turning the box on, I could depress the button, and see the blue glow, but it wouldn't catch, so when I removed my finger, the glow went away.  I was afraid that I'd have to pull the box, but after a few more button toggles, I got it to stay on.  I'm leaving it for now, but we should remember that this may be a problem.

I will look at the phases of all the PDs, but none should need changing except POP 110.  Every other PD has the exact same cables as before.

I checked the demod phases for AS55, POP110, and all the REFL PDs. 

AS55:  I locked MICH, and shook the ITMs (+1 for Y, -1 for X), and watched the AS55 I & Q spectra at 580Hz (notch in the servo was enabled).  I rotated the phase from -32.0 to +13.0 to get the signal entirely in the Q phase.

POP110:  I locked the PRMI (triggering on POP22), and maximized POP22.  I then rotated the phase of POP110 until the signal was maximally positive.  I forgot what the starting phase was, but it is now 84.  The POP11_I signal was entirely negative when I started, so the new phase is about 180 from the old phase.  I also checked by unlocking the cavity, and seeing that a large peak in POPDC corresponded to large negative dips in POP110_I and POP22_I.

REFL PDs:  I locked the PRMI, and shook the PRM (notches in the servos were enabled for both MICH and PRCL).  Maximized the peak in the I phase.  REFL11 was fine, REFL33 was fine.  REFL55 was changed from 120 to 45.  REFL165 was changed from 106 to 96.

I restored the SRM on the IFO_ALIGN screen, but the saved value was almost 2 full integers off in yaw from actual DRMI resonances.  It looks like it was saved when Rana and I were working late last week.  We must have accidentally saved it when it was misaligned, since hysteresis can't do that much.

I want to check the phases for POX and POY with arm locking, just in case.  Also need to set the AS110 phase (which is plugged into the AS11 channels - need to fix the channel names).

 Isn't that backwards?  Shouldn't the tickler be enabled by the down script, and disabled by the up script?  Either way, the problem was that, after I acquired lock, the tickler was causing the transmitted power to fluctuate by ~20%, and often the MC would lose lock after a minute or so.  Also, the WFS definitely couldn't be enabled by hand. 

Anyhow, I'll try to keep in mind that this exists, so I'm not stymied by it again.

I have modified the c1lsc model so that I have access to the AS110 channels in the triggering and power normalization matrices. 

I also put in a few blocks so that we can have triggering on the violin notches that we moved to the LSC model a week or so ago. 

Here is my svn comment, so I don't have to retype things:

2 changes:  AS110 channels added, and Violin filter triggers added.

AS110:     We recently installed a    new demod board    and PD for an AS110 signal.  Since we will not    be using AS11 in the forseeable    future,    the AS110 demod    board outputs use the former AS11 channels.  I    have left the AS11 channels in the model so that we can easily    add them back if we want to, but they are grounded rather than    connected to the ADC.  I've added digital demodulation for AS110, power normalization,    and then added the I&Q signals to both the trigger matrix and the main    power normalization matrix.  NOTE that these slide the matrix columns around.    Since the AS110    is also    using the former AS11 whitening    channels, swapped those on the    BIO block also.

Violins:  Recently, Rana and I moved the SUS LSC violin    filters    from the individual suspension    models over to the LSC model.  Giving every optic every    optics' violin    notch helps eliminate bad cross-coupling between servo loops.  Here, I have enabled triggering    for these notches, so that the violin filters can come on after a cavity is locked.  Since the    filter banks SHOULD BE THE SAME    for all LSC_SUS banks,    the "mask" is common to    all optics.

I also edited several medm screens, to show the new changes:  the lsc overview screen has a button to the violin notch triggering screen, in addition to being able to get to the new screen from the regular triggering matrix screen.  I made the trigger and normalization matrix screens bigger, since there are now 2 new columns. 

I added AS110 to both the LSCoffsets script, and Masayuki's new, better, LSCoffsets2.py. 

I added new lines to the .req files for the ifo configure burt restores for the new matrix columns, and the violin triggering.

I restored, checked out, and saved the Xarm, Yarm, MICH, PRM_sb, and DRM configurations. 

I tried locking the DRMI, but haven't really been successful.  I'm not 100% sure how to do the phasing for AS110, so that could be a problem.  For POP, I can watch POPDC to see if something is a carrier or a sideband flash, but I don't have something quite as convenient at the AS port.  I have set the AS110 phase to 60 degrees for now, since during free swinging DRMI flashes, it looks like most of the buildup is in the I phase with 60 degrees.  Even with the same configurations as a week or so ago, I'm not getting much more than ~1 second locks.

I also tried locking the SRMI, but am not getting anything at all.  I think I need to go back to simulation-land to figure out what good signals might be.

Other thoughts:

Stefan modified the LSC filter module triggering blocks, so now we have a new epics variable, "_INVERT", which sends the trigger through a NOT or not.  I think that we want to keep this variable set to 0 to be the same as things were, but I do need to expose this new variable on the screens.

The trigger and normalization matrices pictured on the LSC overview screen need to be expanded by the 2 new columns.  The actual matrix screens are good, but I forgot to fix up the little Kissel buttons.

When I have a free swinging SRMI, MICH and SRCL should have the same sign for the gain, if I'm using AS55 I&Q for locking.

LLO is using REFL 9I for SRCL, and ASDC for MICH for the SRMI, but I don't have any REFL beam with a misaligned PRM, so I don't think I can copy what Den and Lisa did on Monday night.

I have figured out / rediscovered why the "sqrt" buttons on the power normalization screen aren't restored when you restart the LSC model - They are controlled by momentary epics records, which go to embedded c-code to do some toggling.  I don't know yet of a good way to save the configuration of these guys for burt restore-type restoration.  This will be a problem for anything that is using these toggle c-codes.

 Seems fine now.

I have the DRMI free swinging right now, since it's not really locking.  Looking at these time series in the attached pdf, particularly around time=1.15, it would be super handy to trigger the SRCL degree of freedom on AS110 after the PRMI is triggered on POP22.

I want something like an "AND" for the degree of freedom triggers.  Koji and I talked through an idea, and I have it running in the c1tst model, but the logic isn't working like I expect, so I need to look into it more before I can put it into the lsc model.

I have done a quickie look at Optickle to see how the linewidth of an arm cavity changes versus the configuration. 

To do this, I make different configurations, and do a sweep of ETMX.  For each configuration, I find the max peak value, and then find the points that are at half that value.  The distance between them is the full width at half max.

I get:

FWHM_DRFPMI = 3.8750e-11  meters

FWHM_PRFPMI = 3.8000e-11  meters

FWHM_SRFPMI = 2.3200e-09  meters

FWHM_FPMI =   1.1900e-09  meters

So, for the ALS to hold within 1/10th of a linewidth for the full IFO configuration, we want the ALS noise to be on the order of 3 picometers RMS.  If I recall correctly, that's about an order of magnitude better than we currently have.

                 use LOG y-scale

EDIT 8 Nov 2013, JCD:  New log-y plot:

I have modified the ASS model to also have an ASS for SRCL.  The input options are POPDC, POP110, AS110.  I suppose I could/should have included ASDC.

Screens are modified / made.  I haven't finished setting the servo gains and oscillator amplitudes, and all that jazz yet. 

Using the parameters that Koji had in elog 9116, I was able to get nice long DRMI locks (several on a ~10 minute time scale). 

I tried some pseudo-ANDing for the triggers, to no avail.  I was trying to have the trigger matrix row for the SRCL loop have 1*POP22 and 0.02*AS110, where the 0.02 is to scale AS110 so that it has a similar amplitude to POP22.  I then set threshold levels to ~250 for up, and 100 for down (I tried several different values for the up threshold).  I was watching the TRIG_MON_FAST channels for both PRCL and SRCL, and I wasn't able to get SRCL to be triggered only at the same times as PRCL using this technique.  Since we can get the DRMI to lock, perhaps my AND logic for the triggers is a low priority, but I think we'll need something like that if we want real logic.

First up for me this evening was getting the PRMI locked.

I used the IFO configure screen to lock the X and Y arms, then aligned them using the ASS scripts.  Then used the IFO config screen to restore the Michelson, and did some fine tune tweaking of the BS alignment by looking at the AS camera.  Then, I restored the PRMI from the IFO config screen, tweaked the PRM a little bit in yaw, and was able to get a lock using REFL 165 I&Q for ~25 minutes before I got bored and unlocked things.  I used the ASS for the PRM to align the PRM, then turned off the ASS.  POP110 and POP22 both drifted down, but by a small amount, and at the end (when I turned the ASS back on for PRM), they picked back up to about their original levels.

(Note to self: to get it to print both plots, chose custom paper size, make it 14.5 by 11.  Don't ask why, just do it, because it works.  Also, in PNG device properties, increase the compression to 9.)

After I played with the PRMI, I started looking at the ALS system. 

I had both arms locked on IR using the regular LSC system (so POX and POY for the error signals).  Then I opened up the green shutters, and got both arms locked on green (so the green lasers were just following the arms...no digital ALS business).  I went out to the PSL table and tweaked up the alignment of the green beams (didn't need much at all, just an itsy bitsy bit in yaw, mostly).  I saw a very strong peak for the Yarm vs. PSL (around -19dBm), and there was a harmonic of that beat.  Opening and closing the Xarm green shutter had no effect on these peaks, so there wasn't any kind of X-Y cross beat sneaking around that I could see.  That's really as far as I got - I think (but haven't checked) that Manasa may have removed the power splitter / combiner, so that the RF analyzer is only looking at the Y beat PD (she mentioned earlier today that she was going to give that a try to narrow things down). 

After that, Rana and I went back to the PRMI for some noise stuff, and worked on the PMC.  See those separate elogs for info on those activites.

Someone left the arms aligned, and the LSC engaged, so the arms have been locked almost continuously for several days hours.  The trend below is for 4 days hours.  What is most impressive to me is that we don't see a big degredation in the transmitted power over this time.

EDIT: Okay, I got excited without paying attention to units.  It was only several hours, which is not too unusual.  Although the lack of transmission degredation is still unusual.  However, this may be due to improved oplevs?  I'm not sure why, but we're not seeing (at least in this plot) the degredation to ~0.7 after an hour or so.

Something is really excellent with the alignment today, or something has changed with the POP path / electronics.  While usually we see ~120 counts on POP22_I and ~175 counts on POP110_I (cf elog 9193), today I have ~175 counts on POP22_I and ~265 counts on POP110_I.

I have resaved the PRMI locking settings in the IFO Config screen.  Nothing has changed, except that I have put a 1e-4 into the PRCL matrix elements for REFL11I, REFL33I and REFL55I.  So, PRMI still locks on REFL165 I&Q, but the other 3 REFL diodes' whitening gets triggered when the cavity is locked.  I think this will help the LSC sensing matrix measurements, which I'm going to test out now.

I discovered that I was not getting enough SNR on all the refl RFPDs when I actuated using the Sensing Matrix script.  The problem was that the ITMs have actuation constants that are a factor of 5 lower than the PRM.  So, I need to push on the ITMs (for MICH) about 5 times as hard as I push on the PRM (for PRCL).  I have modified the sensing matrix scripts to allow different actuation amplitudes for each degree of freedom.  If I watch the REFL PD spectra while the script is running, I see that I now have some actual SNR (as in, more than 1, which is what the SNR was for some diodes previously). 

A consequence of this is that the script to analyze past data will no longer work on sensing matrix data taken before this afternoon.  On the other hand, that data isn't very useful, since there was no SNR.

 Rana and I noticed last week that it looked like the REFL11 beam was clipping.  This afternoon, I locked the PRMI with REFL 165 I&Q, and checked the REFL 11 path.  The beam looks fine through all of the optics going to the diode, so I just realigned the beam onto the diode using the itty bitty steering mirror.  I have not yet checked the change (hopefully improvement) in the REFL11 spectrum.

I have modified the LSC model (the currently-running model is checked into the svn), but it is not compiling for me.  So, if you need to make changes to it, be careful, and probably save my version off to the side, and checkout the latest svn version.  (I don't foresee anyone needing to modify this model any time soon though).

The change that I'm trying to make is adding several more lockin setups, so that we can measure the sensing matrix elements for several degrees of freedom simultaneously. 

Right now, the error that I'm getting is the frustrating "something isn't connected" error, even though if you look in the model, the part that it mentions is fully connected.  Usually the solution to this is to disconnect and reconnect everything, so I'll work on that after I return to the lab in a bit.

The modifications to the LSC model are now complete, and the new model has been compiled, installed, and is running. The sensing matrix lockins are all in the c1cal model.  Masayuki is locking right now, so so far, things appear to be back to normal.

The longer version of the story, with all the detours and hiccups:

After several tries of deleting the GoTo and From flags / tags in the lockin area of the LSC model, and continually getting the "something is not connected" errors, I gave up and just drew several long lines.  So, in the new Sensing Matrix block (which is actually in c1cal, not c1lsc, but that's a story for the next paragraph), we should eventually make things back to the more clean flags situation, but for right now, it's working, with lots of lines everywhere.  I've tried to be very organized and clear about what lines go where, so that it's easy to see what's going on.

I eventually was able to compile c1lsc, and then installed it, and restarted the model.  Adding in 5x the lockin modules (we had 27, but now we have 5x27, so that we can look at the sensing matrix elements for every degree of freedom, and every photodiode, all at the same time) was too much for the poor lsc cpu.  I was consistently getting over 70usec per cycle, and was hitting a max of 77usec for the lsc cpu.  Both of those numbers are greater than the allowed 60usec.  So, I made the decision to put the whole sensing matrix / lockin stuff into the calibration model.  This means that I have 27+5 more IPC signals than I used to, but so far things seem to be okay (no rigorous testing yet).  (27 to send the 27 PD inputs over to the cal model, and another 5 to send the oscillator "clocks" from the cal model to the lsc model.)  The lsc model is now running faster than before (because there were 27 lockin modules in the model), at 24-28 usec, and the cal model is running at 39usec.

All seemed well and good, both the lsc and cal models compiled, but the lsc burt restore wasn't working.  Restarting the model did not successfully do a burt restore, and when I tried several different .snap files from today, and other times this month using burtgooey, I kept getting "NOT OK", and numbers weren't being restored into the epics channels.  A very few settings were restored, but most were not.  I ended up copying a .snap file from a few hours ago into a separate directory, then went in and by-hand removed all the lines referring to now non-existant lockin channels.  Burtgooey still told me "NOT OK", but settings seem to be restored, so I think it's okay.  I have not confirmed each and every one of the 10,000+ channels to ensure that the number is the same as the one in the .snap file, but as I glance around in the LSC screen and its dependants, all the numbers and buttons look about right.  

After all this stuff, Masayuki is locking both arms simultaneously in IR, as he prepares to test some new ALS scripts, so things seem okay for now.

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.

For my work designing a cost function, so that I can try out new feedback servo designs on the oplevs, I wanted to know what the dark noise of an oplev is.  Since the pitch and yaw channels are divided by the sum channel, when the laser is off, the noise in the pitch and yaw channels looks much higher than it really is.  So, I collected some data from the 4 individual quadrants of the ITMY oplev, when the laser was on (but damping was off), and when the laser was off.  I used the values of the oplev input matrix to re-create the non-normalized pitch and yaw signals.  What I see is that we have some kind of real signal below 1 kHz, but we're hitting the noise at around 1 kHz.  So, we definitely don't want to use oplev error signal information above 1 kHz when designing new servos.

The last word in the title is "off".  OSEM damping was on, but the oplev damping was off.  These are uncalibrated, because the calibrations that we have to go from counts to microradians are for the normalized signals. 

 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.

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

 The PMC refl is bad in pitch today, and the transmission is only 0.76, rather than our usual 0.83ish.

I did a quick, rough tweak-up of the alignment, and now we're at 0.825 in transmission.

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. 

Plots:

PRCL Open Loop Transfer Function.  PRMI locked on REFL 165 I&Q, Xarm held on IR resonance using ALS, ETMY misaligned:

MICH Open Loop Transfer Function.  PRMI locked on REFL 165 I&Q, Xarm held on IR resonance using ALS, ETMY misaligned:

 Time series data during our PRMI + 2 arm attempt:

 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.

Koji reminded me that we should also save the data from the PRMI+Xarm, just in case we want to look at it later.

Here is the time series, in which you can see us finding the Xarm IR resonance, moving the arm off resonance, locking PRMI, and bringing the arm back into resonance.  At the very end, the arm is still held on resonance, but I had disabled the LSC locking, so we see very large flashes at TRX (of order 40, rather than 1).

The data is in the same folder as the 2arm data: /users/jenne/PRCL/PRMI_Xarm_ALS_16Oct2013/

The text files have been differentiated, so that the 2arm data has "_2arms" at the end of the filename, while the Xarm data had "_Xarm" appended to the filename. Since we left the cavities locked for many minutes (during which transfer functions were taken), the data set for the PRMI+Xarm is very long.

I locked the PRMI, and tried to turn on the ASS, but this caused PRMI to lose lock. 

Since this is similar to what happened the other night (see elog 9243, 2nd big paragraph), I looked into it a little further.  I noticed that the POP QPD pitch was very close to the edge of the QPD, so I went out and (while PRMI was locked) recentered the POP QPD.  After doing so, I was able to run the PRM ASS, and it worked very nicely, just as it has before.  So, it looks like something drifted, such that the optimal PRM alignment caused the POP beam to not be fully on the QPD.  Since the ASC loop is triggered by PRMI lock, and is constantly on, falling off the QPD causes lockloss.

While I was out there, I tweaked up the PMC pitch alignment yet again.  The FSS numbers all looked reasonable, however PMC transmission was ~0.75 .  I did a tiny bit of work in pitch, and now we're back to 0.83 transmission. 

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.

The PMC was unlocked for a little over an hour.  I relocked it, and the MC locked itself.  Today, it looks like PMC yaw alignment is bad, and maybe pitch isn't so good either.  Transmission is 0.77

We have now watched the ETMY computer situation for a little over 150 minutes, and have seen one 'event' where the CPU time of the scy model hit 62 microseconds, and a glitch in the ETMY OSEM sensors happened at the same time.  We also see no such glitches at any other time, which makes sense with our latest hypothesis, since this event was the only time that the CPU time reported being greater than 61 microseconds.  (1/16384 Hz = 61.1696 microseconds). 

I have now restarted the c1tst model, to see if that increases the rate of glitches (assuming that running another model heats up the whole computer a bit more, and that makes things run a little bit slower).

Wed Oct 23 21:05:28 2013 

RXA: It looks like there was a real effect. Its between -2.5 and 0 on the plot below.

I've stopped the process of c1tst again to make it get better. At 9:20, I also went and opened the front rack door (the back one was already open). One reason its hot may be that the exhaust vents on the top of c1iscey are blocked by one of the custom multi-pin adaptor boxes. In the morning, we should drop the computer down by 1 or 2 notches in the rack so that it can air cool itself better. Make sure to poweroff the computer from the terminal before moving it though.

I checked the cabling somewhat. The fat grey cable which comes out of the old Sander Liu AA chassis was connected to the blue adaptor box but the strain relief screws were not being used. I tightened them (we need to buy a set of small screwdrivers for the toolboxes at each end). While doing this, the Cat6 cable in the back labeled 'c1iscey' popped out and the screen went white. This cable has a broken latch on it so it doesn't stay put - needs to be replaced too during the computer move.

As you may recall, Den designed some nice seismometer stations for us with the help of Steve. The granite base was installed : elog 8461. The point of these is to have nice solid bases for our seismometers to sit on, rather than the flimsy linoleum flooring.  Also, they are covered (and will be insulated) to help prevent air currents and temperature fluctuations from affecting our seismometer measurements.  Even though these seismometer stations have been in place for a few months, we are not yet taking advantage of them.  This is a status elog, so that we know what needs to be done.

Recently, Den finished up the design for, and Steve ordered, and we received, the small aluminum plates that go on the side of the granite slabs, so that we can feed the connectors for the seismometer through the baseplate, in an airtight way. 

The current plan is to use one Guralp at each end station, and the Trillium at the vertex.  As of this moment, we have 1 Guralp at ETMY, 1 Guralp at ITMX, and a Streckeisen at ETMX, and the Trillium is sitting to the south of the POX table.

Most of the work that's left to do is just to place the seismometers on the new stations, and to make cables.

I have taken an inventory of all the things that I think we need to buy (or I need to find in the lab) in order for us to finish this project up.

We need to buy a LEMO connector for the T-240 plate. 

We need to buy 6 O-rings:  3 to go between each aluminum plate and the granite slabs, the other 3 between the plate and the milspec connectors for the seismometer cables.

We need to buy or confirm that we have screws to attach the plates to the granite slabs.

We need to buy or confirm that we have screws to attach the milspec connectors to the plates.

I need to confirm that I have another 37-pin dsub for the Xarm Guralp cable, and a 25-pin dsub for the Trillium.

Assuming that I am reusing the existing Yarm Guralp cable, we have all the milspec connectors necessary.

I have a 30m long spool of 19-pair cable that I will use to make the Trillium cable.  I have a long cable, formerly a Streckeisen cable, that I will cut the ends off of, and make into a Guralp cable.  (We had 3 of these incredibly long, maybe ~50m cables - one became the Yarm Guralp cable, one is waiting to be the new Xarm Guralp cable, and the 3rd one is connected to the Streckeisen that we still have).

Work to be done:

* Make long cables for Xarm Guralp and Vertex Trillium.  Check pinouts for the milspec -> dsub connections on each cable.

* Make small cables that go inside of the granite and seismometer station.  These are to connect the sensor to the aluminum plate, and then the long cables go from the plate to the readout box.  Unfortunately, the holes in the granite are not large enough to pass a connector through, so these will have to be soldered in-situ. 

* Plug in the Trillium readout box and confirm that it's working / makes sense.

Longer term modifications and add-ons:

* Lemo connector with wiring for temperature and pressure sensors inside the vertex station.  I believe that Den was looking into what sensors we might want.

* Needle valve for slow pressure equalization on vertex station (all stations should have this, but only the Trillium plate has a hole for this). 

Is there anything else that I'm forgetting??  Please reply with thoughts.

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.

[Masayuki, Jenne, Rana]

We have, for the past hour and a few minutes, had PRMI + 2 arms locked.  Yup, that's right, we did it! (We never gave control of the arms to the IR LSC system, so it's kind of cheating, but it was still cool.)

A little after midnight, we felt that the Yarm was behaving well enough that we could give PRMI + 2 arms a try.  So we did.  Probably around 1am-ish, or maybe a little bit before, we had the system locked. 

How did we do it?

* Locked arms in IR to help find green beatnotes.

* Misalign ETMs, lock and align PRMI.

* Misalign PRM.

* Restore ETMs, find arm resonances, then step away (I did +3 counts, which is 29 kHz).

* Restore PRM, lock PRMI.

* Brought Xarm back close to resonance using ALS (-3 counts). It seems like this may not actually have gotten us back to perfect resonance, but that actually made bringing in the other arm easier.

* Brought Yarm back close to resonance using ALS (-3 counts). 

* Turned on Sensing Matrix notches and oscillators (10,000 counts for MICH, actuating on BS and PRM at 562.01 Hz, 200 counts for PRCL actuating on PRM at 564.01 Hz). 

* Stepped arms back and forth to see how things responded.

Notes:

During this process, particularly during the various arm steps, the PRMI lost lock many times.  However, the ALS system never lost lock for either arm, for an hour and a half or so.  Good work, ALS team!!  The PRMI would reaquire lock (sometimes we'd have to undo whatever arm step we just took, to get farther away from resonance) without any intervention.  It seemed that as we came closer to full arm resonance, we were never able to hold PRMI locked.  This is what is instigating some of our investigations for tomorrow.

Also, Rana reported to me that he turned the c1tst model back off, and opened the door(s?) to the ETMY rack to allow more air flow sometime before midnight, which seems to have reduced the rate of the CPU going over 61 microseconds, as well as reduced the number of times the ETMY suspension glitches.  We definitely need to make some changes so that we're not so close to the edge.  This may have been one of the big things that allowed our success tonight.

The transmission PDs at the ends of the arms are saturating around 50 counts (they have gains of 2e-3 so that they are roughly normalized to 1 being the max power in a single arm).  We need to commission the end transmission QPDs. 

All of the signals looked a little ratty, and we heard lots of noise - Rana suggests that we recommission our CARM servo.

ALS beat info:  [Xarm  40.9 MHz,  -11.4 dB], [Yarm  50.5 MHz,  -17.7 dB]

Things to look at tomorrow:

Data!  I should be able to extract sensing matrix information, even though my sensing matrix software isn't totally ready yet.  I know what the oscillators were doing, and I can look at the PD error signals.  We also save the Offsetter numbers, so I can kind of tell what the PRMI+arms situation was. 

Can we tell by looking at the end laser PZT feedback signals whether we're making our arms longer or shorter?  So that we can tell if we're putting on DARM or CARM offsets.

Spectrum and time series of REFL 165 (our PRMI LSC locking PD) to see if we're saturating while we bring the arms into resonance.  Basically, does anything bad happen, particularly since the PD is not a resonant PD, so there are some 1f signals floating around in addition to the 3f signals.  We want to put in a directional coupler after the PD, before the demod board, and send that signal to a spectrum analyzer and a 'scope.  Hopefully we can use the power of the internet to not need to sit in the IFO room saving data as we move the arms around.  Do we need to put bandpass filters on the PD signal before it goes to the demod board?

Optickle model of 1f vs. 3f signals in the different ports, as the CARM offset is reduced.

Violin notches for the arms - should be put into ALS and LSC models.  It looks like the modes are around 631 Hz, but we should check. 

Hardware for end low gain transmission QPDs.

Software (schmidt triggering) for end transmission QPDs.

Modifying / preparing a matrix in the ALS system so that we can give CARM and DARM offsets conveniently.

 I have modified the ETM suspension models to include a schmidt triggering block, so that we can choose between using the high gain low power Thorlabs PD and the low gain high power QPD. 

The Thorlabs high gain PD signal is used as the signal to trigger on, so we need to put appropriate thresholds in.

If things are "triggered", that will imply that the Thorlabs PD is seeing a lot of power, so we should be using the QPD SUM channel instead.  There is a "choice" block after the trigger block, to do this switching.

Since the LSC model will only see the output of this choice block, the gain that is currently in C1:LSC-TR[X or Y]_GAIN should be moved to the end SUS model.  We also need to find the correct gain for the QPD sum channels so that they are also normalized to "1" for single arm full power so that we can smoothly go between the 2 diodes.

Rana has promised to make screens, and write scripts for the switching stuff.

We were locking the PRMI, but it is very rumbly today.  I reduced the MICH servo gain from -0.8 to -0.4 , and things seem to be better.  Now my MICH UGF is about 60Hz.

 Neither of these computers were listed in the Martian Host Table in the wiki, so I put them on there.  It's handy to keep this updated, so that we know what IP addresses are available.

Masayuki was concerned that some LSC channels were giving him all zeros.  After seeing the error in the terminal window running dataviewer (it said something like 'daqd overloaded'), I checked the lsc model, and sure enough, all the test points were used.

So, I found an entry by Jamie (elog 8431) where he reminds us how to clear the test points.  I followed the instructions, and now we're seeing real data (not digital zeros) again.

As we are meditating on things to look at for PRMI + 2 arms, Rana brought up the question of the demod board situation. 

We then found this table on the wiki (LSC demod boards) that indicates that all of the demod boards were originally given lowpass filters, no matter the demodulation frequency.  Back in September, I switched out the low pass filter for a bandpass filter in POP110, and put in the same bandpass when putting together AS110 (elog 9100).  So, the 11MHz diodes are probably okay with lowpasses, and the 110 diodes are okay, but we need to think about all the other ones. 

We should probably do a first guess by putting in a bandpass filter, but then simulate and measure to figure out what our requirements are for attenuation at the non-demodulation frequencies for each board.

The SXBPs from Minicircuits look pretty good, but there are lots of options on their website.

For tonight, Rana has put a coax 100 MHz highpass filter on the input to the REFL165 demod board.

 This of course changes our demod phase.  Rana plotted a 4th order elliptic filter in Matlab, and from the plot determined that we should expect around 60 degrees of difference in our phase. 

To actually set the phase, I locked PRMI on AS55Q and REFL33I (MICH gain = -8.0, PRCL gain = +0.05, with 1's in the matrix elements).  I then turned on the PRCL oscillation notch (564 Hz), and turned on the sensing matrix's drive at that frequency, and looked at the spectrum of REFL165. 

The previous REFL165 demod phase was 96 degrees, so I was looking around either 36 degrees or 156 degrees.  The phase that minimized the peak in the Q signal while driving PRCL was 37.5 degrees.  Good work Matlab/Rana.

I then looked at the transfer functions between REFL33 and AS55 and REFL165, to see if there were any sign flips that happened.  There were not.  As expected, it was just a little extra phase delay.

I was able to lock PRMI with REFL 165 again after this phasing, and I am now taking transfer functions of the MICH and PRCL loops to make sure that we have the gains about right.

 I have set the PRCL UGF to be about 180Hz, and the MICH UGF to be about 70 Hz. 

This is with locking on REFL165 I&Q, with MICH gain of -2.0 and PRCL gain of 0.70 . 

The PRCL loop only has about 30 degrees of phase margin, and is not near the top of its phase bubble.  During the day, I need to look at why we don't have more phase near 200 Hz.