40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 59 of 344  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  14975   Thu Oct 17 12:34:51 2019 gautamUpdateGeneralDaytime wishlist

Some ideas that would help increase the locking duty-cycle in the short term. 

  1. Seismometer investigation - something is not quite right with the vertex seismometer. This is the one that is primarily used for feedforward, and can be really helpful.
  2. Drifting TTs - it is really annoying to have to re-set the input pointing into the interferometer every ~ hour. See Attachment #1.
  3. FSS - this isn't a scientific statement, but there were ~20-30 minute periods last night where the PC drive RMS was displaying sharp spikes repeating every 2-3 seconds, first with increasing and then decreasing height. This is a new feature to me in the long standing PC drive saga but it doesn't tell me exactly what is going on as I don't know in what frequency band the glitch is actually happening. See Attachment #2.
  4. ALS noise - while it is possible now to routinely transition the arm length control from the POX/POY to CARM/DARM basis, I see some sharp (<0.1 s) dives in the TRX/TRY levels when the arms are under ALS control. This wasn't present a week ago. Needs to be investigated - I defer this to the daytime tomorrow.
  13010   Tue May 23 22:58:23 2017 gautamUpdateGeneralDe-Whitening board noises

Summary:

I wanted to match a noise model to noise measurement for the coil-driver de-whitening boards. The main objectives were:

  1. Make sure the various poles/zeros of the Bi-Quad stages and the output stage were as expected from the schematics
  2. Figure out which components are dominating the noise contribution, so that these can be prioritized while swapping out the existing thick-film resistors on the board for lower noise thin-film ones
  3. Compare the noise performance of the existing configuration, which uses an LT1128 op-amp (max output current ~20mA) to drive the input of the coil-driver board, with that when we use a TLE2027 (max output current ~50mA) instead. This last change is motivated by the fact that an earlier noise-simulation suggested that the Johnson noise of the 1kohm input resistor on the coil driver board was one of the major noise contributors in the de-whitening board + coil driver board signal chain. Since the TLE2027 can drive an output current of up to 300mA, we could reduce the input impedance of the coil-driver board to mitigate this noise source to some extent. 

Measurement:

  • The back-plane pin controlling the MAX333A that determines whether de-whitening is engaged or not (P1A) was pulled to ground (by means of one of the new extender boards given to us by Ben Abbott). So two de-whitening stages were engaged for subsequent tests.
  • I first measured the transfer function of the signal path with whitening engaged, and then fit my LISO model to the measurement to tweak the values of the various components. This fitted file is what I used for subsequent noise analysis. 
  • ​For the noise measurement, I shorted the input of the de-whitening board (10-pin IDE connector) directly to ground.
  • I then measured the voltage noise at the front-panel SMA connector with the SR785
  • The measurements were only done for 1 channel (CH1, which is the UL coil) for 4 de-whitening boards (2 ITMs, BS, and SRM). The 2 ITM boards are basically identical, and the BS and SRM boards are similar. Here, only results for the board labelled "ITMX" are presented.
  • For this board, I also measured the output voltage noise when the LT1128 was replaced with a TLE2027 (SOIC package, soldered onto a SOIC-to-DIP adaptor). Steve has found (ordered?) some DIP variants of this IC, so we can compare its noise performance when we get it.

Results:

  • Attachment #1 shows the modeled and measured noises, which are in fairly good agreement.
  • The transfer function measurement/fitting (not attached) also suggests that the poles/zeros in the signal path are where we expect as per the schematic. I had already verified the various resistances, but now we can be confident that the capacitance values on the schematic are also correct. 
  • The LT1128 and TLE2027 show pretty much identical noise performance.
  • The SR785 noise floor was low enough to allow this measurement without any pre-amp in between. 
  • I have identified 3 resistors from the LISO model that dominate the noise (all 3 are in the Bi-Quad stages), which should be the first to be replaced. 
  • There are some pretty large 60 Hz harmonics visible. I thought I was careful enough avoiding any ground loops in the measurement, and I have gotten some more tips from Koji about how to better set up the measurement. This was a real problem when trying to characterize the Coil Driver noise.

Next steps:

  • I have data from the other 3 boards I pulled out, to be updated shortly.
  • The last piece (?) in this puzzle is the coil driver noise - this needs to be modeled and measured.
  • Once the coil driver board has been characterized, we need to decide what changes to make to these boards. Some things that come to mind at the moment:
    • Replace critical resistors (from noise-performance point of view) with low noise thin film ones.
    • Remove the "fast analog" path on the coil driver boards - these have potentiometers in series with the coil, which we should remove since we are not using this path anyways.
    • Remove all AD797s from both de-whitening and coil driver boards - these are mostly employed as monitor points that go to the backplane connector, which we don't use, and so can be removed.
    • Increase the series resistor at the output of the coil driver (currently, these are either 100ohm or 400ohm depending on the optic/channel). I need to double check the limits on the various LSC servos to make sure we can live with the reduced range we will have if we up these resistances to 1 kohm (which serves to reduce the current noise to the coils, which is ultimately what matters).
  15783   Thu Jan 28 22:34:21 2021 gautamUpdateSUSDe-whitening

Summary:

  1. We will need de-whitening filters for the BHD relay optics in order to meet the displacement noise requirements set out in the DRD. I think these need not be remotely switchable (depends on specifics of LO phase control scheme). SR2, PR2 and PR3 can also have the same config, and probably MC1, MC3 as well.
  2. We will need de-whitening filters for the non test mass core IFO optics (PRM, SRM, BS, and probably MC2).
  3. I am pretty sure we will not be able to have sufficient DAC range for the latter class of optics if we have to:
    1. Supply the DC bias.
    2. Do the LSC and ASC actuation in the presence of reasonable sensing noise levels.
    3. Engage de-whitening to low-pass-filter the DAC noise at ~200 Hz.

Details:

Attachment #1 shows the DAC noise models for the General Standards 16-bit and 18-bit DACs we are expecting to have.

  • The 16-bit model has been validated by me at the 40m a few years ago.
  • We have never used the 18-bit flavor at the 40m, and there are all manner of quirks apparently related to zero crossings and such. So the noise may be up to x2 higher (we won't have as much freedom necessarily as the sites to bias the DAC on one side of the zero crossing if we also need to use the same DAC channel to supply the DC bias current for alignment.

Attachment #2 shows the expected actuation range for DC optic alignment, assuming we use the entire DAC range for this purpose.

  • Clearly, we need to do other things with the same DAC channels as well, so this is very much an upper bound of what will be possible.
  • Let's assume we will not go lower than 100ohms.
  • For all new optics we are suspending, we should aim to get the pitch balancing to within 500urad. With a 2x2m=4m optical lever arm, this corresponds to a 2mm spot shift. Should be doable.
  • This could turn out to be a serious problem for PRM, BS and SRM if we hope to measure squeezing - the <AUX DOF>-->DARM coupling could be at the level of -40dB, and at 200 Hz, the DAC noise would result in PRCL/MICH/SRCL noise at the level of ~10^-15m/rtHz, which would be 10^-17m/rtHz in DARM. I don't think we can get 20dB of feedforward cancellation at these frequencies. For demonstrating locking using a BHD error signal, maybe this is not a big deal.

Attachment #3 shows the current and proposed (by me, just a rough first pass, not optimized in any way yet) de-whitening filter shapes. These shapes can be tweaked for sure.

  • The existing de-whitening filter is way too aggressive. FWIW, the DRD "models" a "4th order Chebyshev low pass filter" which doesn't exist anywhere as far as I know.
  • Since the DAC noise is below 1 uV/rtHz at all frequencies of interest, we never need to have >60dB de-whitening anywhere as the input referred noise of any circuit we build will exceed 1 nV/rtHz.
  • I propose 3 poles, 3 zeros. In the plot, these poles are located at 30Hz, 50Hz, 2kHz, and the zeros are at 300 Hz, 300 Hz, 800 Hz. 
  • The de-whitening is less agressive below 100 Hz, where we still need significant LSC actuation ability. Considering the sensing noise levels at the 40m, I don't know if we can have reasonable LSC and ASC loop shapes and still have the de-whitening.
  • Once again, PRM, SRM and BS will be the most challenging.
  • For the BHD relay optics, once we have the de-whitening, we won't have the option of turning on a high-frequency (~kHz) dither line because of insufficient DAC range. 

Attachment #4 puts everything into displacement noise units. The electronics noise of the coil driver / de-whitening circuit have not been included so at high frequencies, the projection is better than what will actually be realizable, but still well below the BHD requirement of 3e-17 m/rtHz.

  1680   Tue Jun 16 17:38:35 2009 robUpdateLockingDeWhites ON

With the common mode servo bandwidth above 30kHz and the BOOST on (1), I was able to switch on the test mass dewhitening.  Finally.

  17267   Tue Nov 15 16:34:55 2022 alexUpdateGeneralDebian with Sensoray

I have confirmed the ability to install the sensoray drivers on Debian 11 in a virtual machine environment. I will do testing with the sensoray device on this tomorrow and if all works, begin working on code for capturing images. I will then test this out on Donatella once Tega finishes installing Debian across all computers in the coming week or so. 

  3216   Wed Jul 14 11:54:33 2010 josephbUpdateDAQDebugging Guralp and reboots

This is regards to zero signal being reported by the channels C1:PEM-SEIS_GUR1_X, C1:PEM-SEIS_GUR1_Y, and C1:PEM-SEIS_GUR1_Z.

I briefly swapped Guralp 1 EW and Guralp 2 EW to confirm to myself that it was not on the gurlap end (although the fact that its digital zero is highly indicative a digital realm problem).  I then unplugged the 17-32, and then 1-16 channel connections to the 110B.  I saw floating noise on the GUR2 channels, but still digital zero on the GUR1 channels, which means its not the BNC break out box.

There was a spare 110B, unconnected in the crate, so to do a quick test of the 110B, I turned off the crate and swapped the 110Bs, after copying the switch configuration of the first 110B to the second one.  The original 110B was labeled ADC 1, while the second 110B was labeled ADC 0.  The switches were identical except for the ones closest to the Dsub connectors on the front.  All those switches in that set were to the right, when looking down at the switches and the Dsub connectors pointing towards yourself.

Unfortunately, the c0duc1 never seemed to come up with the new 110B (ADC 0).  So we put the original 110B back.  And turned the crate back on. 

The fb then didn't seem to come back quite right.  We tried rebooting fb40m it, but its still red with status 1.  c0daqctrl is green, but c0dcu1 is red, although I'm not positive if thats due to fb40m being in a strange state.  Jenne tried a telnet in to port 8087 and shutdown, but that didn't seem to help.  At this point, we're going to contact Alex when he gets in around 12:30.

 

  3220   Wed Jul 14 16:39:06 2010 JenneUpdateDAQDebugging Guralp and reboots

[Joe, Jenne]

Joe got on the phone with Alex, and Alex's magic Alex intuition told him to ask about the RFM switch.  The C0DAQ_CTRL's overload light was orangeAlex suggested hitting the reset button on that RFM switch, which we did. That fixed everything -> c0dcu1 came back, as did the frame builder.  Rana had pointed out earlier that we could have brought back all of the other front ends, and enabled the damping of the optics even though the FB was still down.  It's okay to leave the front ends & watchdogs on, and just reboot the FB, AWG, and DAQ_CTRL computers if that is necessary.

Anyhow, once the FB was back online, we got around to bringing back all of the front ends (as usual, except for the ones which are unplugged because they're in the middle of being upgraded).  Everything is back online now.

After all of this craziness, all of the Guralp channels are working happily again. It is still unknown why they starting being digital zero, but they're back again. Maybe I should have rebooted the frame builder in addition to c0dcu1 last night?

 

Quote:

This is regards to zero signal being reported by the channels C1:PEM-SEIS_GUR1_X, C1:PEM-SEIS_GUR1_Y, and C1:PEM-SEIS_GUR1_Z.

I briefly swapped Guralp 1 EW and Guralp 2 EW to confirm to myself that it was not on the gurlap end (although the fact that its digital zero is highly indicative a digital realm problem).  I then unplugged the 17-32, and then 1-16 channel connections to the 110B.  I saw floating noise on the GUR2 channels, but still digital zero on the GUR1 channels, which means its not the BNC break out box.

There was a spare 110B, unconnected in the crate, so to do a quick test of the 110B, I turned off the crate and swapped the 110Bs, after copying the switch configuration of the first 110B to the second one.  The original 110B was labeled ADC 1, while the second 110B was labeled ADC 0.  The switches were identical except for the ones closest to the Dsub connectors on the front.  All those switches in that set were to the right, when looking down at the switches and the Dsub connectors pointing towards yourself.

Unfortunately, the c0duc1 never seemed to come up with the new 110B (ADC 0).  So we put the original 110B back.  And turned the crate back on. 

The fb then didn't seem to come back quite right.  We tried rebooting fb40m it, but its still red with status 1.  c0daqctrl is green, but c0dcu1 is red, although I'm not positive if thats due to fb40m being in a strange state.  Jenne tried a telnet in to port 8087 and shutdown, but that didn't seem to help.  At this point, we're going to contact Alex when he gets in around 12:30.

 

 

  7174   Tue Aug 14 11:39:13 2012 Jamie, Rolf, AlexUpdateCDSDebugging of c1sus machine and c1rfm models

Rolf and Alex came over this morning to see if they could help debug some issues we have been seeing with IPC transmission between the c1sus and c1lsc machines.

c1oaf, which runs on c1lsc, sees a lot of transmission errors on it's dolphin receivers from c1rfm, which runs on c1sus.  Their speculation is that c1rfm is trying to process too many channels, and it's not able to read off all the RFM channels and retransmit them over dolphin to c1lsc before the end of cycle.  To test this they turned off all RFM reads on c1rfm and the dolphin receiver errors on c1lsc all went away.  We ran into other problems before I had a chance to pester them about what the take-away is here.  We might just need to reduce the load on c1rfm, maybe by introducing a c1rfm2?

We then tried to debug an issue in the c1sus machine where models would occasionally run slow for a cycle, or run slow when a different model on the machine was loaded or unloaded.  The suspect was BIOS settings.  Unfortunately, we ran into trouble when we tried to tweak the BIOS setting on c1sus.  We found that all the serial/COM ports were on, which is usually a big no-no for the RTS (the interrupts cause many cycle delays).  However, turning off the COM ports prevented the machine from booting at all.  This was a big mystery.  The machine seemed to be acting flaky in general as well, since the boot (pre-kernel) would hang in various places after different reboots.  Alex went to grab us a spare machine that we're going to try swapping out this afternoon.

  7176   Tue Aug 14 11:49:15 2012 DenUpdateCDSDebugging of c1sus machine and c1rfm models

Quote:

 

  We might just need to reduce the load on c1rfm, maybe by introducing a c1rfm2?

 

 A huge data flow goes from PEM to OAF through RFM. I think we need to make PEM and OAF run on the same machine and transmit signals through the shared memory.

  4406   Fri Mar 11 18:32:45 2011 josephb, Chris, JamieUpdateCDSDebugging simplant damping

The FM1 filter module change for XXSEN was propagated to the ETMX suspension.  This was a change from a 30,100:3 with a DC gain of 1 to a 3:30 which just compensates the hardware filter.

The good gains for the Sim damping were found to be:  100 for ETMX_SUSPOS, 0.1 ETMX_SUSPIT, and 0.1 ETMX_SUSYAW, ETMX_SUSSIDE is -70.  Gains much higher tended to saturate the simulated coils (i.e. hitting 10V limit) and then had to have the histories cleared for the RESPONSE matrix.

These seem to work to damp the real ETMX as well.

  10775   Wed Dec 10 16:12:29 2014 manasaSummaryGeneralDec 10 - PSL table

Quote:

Attached is the timeline for Frequency Offset Locking related activities. All activities will be done mostly in morning and early afternoon hours.

I was working around the PSL table today.

I wanted to modify the telescope that couples PSL light into the fiber; now that I have the translation stages for the lenses. I could not finish it as the locking work started earlier than usual this afternoon. I measured the out of loop noise for ALS error signals before I opened the PSL enclosure. X and Y beat notes were at -18dBm at 49.3MHz and -29.56dBm at 62.2MHz for this measurement. DTT data can be found in /users/manasa/data/141210/ALSoutLoop.xml; so there is reference to go back to in case of any damage done due to the work on the PSL table.

Also, I received the front and back panels for the Fiber chassis and put it together. Find photos (front panel and inside) of chassis in attachment. This will go inside the PSL enclosure tomorrow.

FiberMod_front.jpg    FOL_fiber.jpg

 

  10792   Fri Dec 12 15:19:04 2014 manasaSummaryGeneralDec 12 - PSL table

Quote:

Unfortunately the order placed for beam samplers last week did not go through. These will be used at the X and Y end tables to dump the unwanted light appropriately. Since they will not be here until Tuesday, I revised the timeline for FOL related activities accordingly.

I was working on the PSL table today. 

Since the rejected 1064nm light after the SHG crystal is not easily reachable to measure beam widths close to the waist, I put a lens f=300mm and measured the beam size around its focus. I used this data and redesigned the telescope using 'a la mode'.

I used a beam splitter to attenuate the beam directed towards the fiber. The reflected beam from BS has been dumped (I need to find a better beam dump than what is being used right now. 

I have only ~200uW at the input of the fiber coupler after the BS and 86uW at the output of the fiber (43% coupling)

I moved the GTRY DC photodiode and the lens in front of it to make space for the fiber coupler mount.

The layout on the PSL table right now is as shown below.

PSLtoFiber.png 

I have also put the fiber chassis inside the PSL enclosure on the rack. I moved the coherent spectrum analyser controller that is not being used to make space on the rack.

PSLfiberChassis.png

 
  10765   Mon Dec 8 15:54:39 2014 manasaSummaryGeneralDec 8 - Check Frequency Counter module

Quote:

Attached is the timeline for Frequency Offset Locking related activities. All activities will be done mostly in morning and early afternoon hours.

[Diego, Manasa]

We looked into the configuration and settings that the frequency counters (FC) and Domenica (the R pi to which the FCs talk to) were left at . After poking around for a few hours, we were able to readout the FC output and see it on StripTool as well.

We have made a list of modifications that should be done on Domenica and to the readout scripts to make the FC module automated and user-friendly.

I will prepare a user manual that will go on the wiki once these changes are made.

 

  10766   Mon Dec 8 20:53:51 2014 diegoSummaryGeneralDec 8 - Check Frequency Counter module

Quote:

Quote:

Attached is the timeline for Frequency Offset Locking related activities. All activities will be done mostly in morning and early afternoon hours.

[Diego, Manasa]

We looked into the configuration and settings that the frequency counters (FC) and Domenica (the R pi to which the FCs talk to) were left at . After poking around for a few hours, we were able to readout the FC output and see it on StripTool as well.

We have made a list of modifications that should be done on Domenica and to the readout scripts to make the FC module automated and user-friendly.

I will prepare a user manual that will go on the wiki once these changes are made.

 

 OUTDATED: see elog 10779

 

I started working on the scripts/FOL directory (I did a backup before tampering around!):

  • I still need to make some serious polishing in the folder, and into the Raspberry Pi itself, in order to have a clean and understandable environment;
  • as of now, I created an single armFC.c program, which takes as arguments the device (/dev/hidraw0 for the X arm, and /dev/hidraw1 for the Y arm) and the value to write into the frequency counter (0x3 for initialization and 0x2 for actual use); hence, no more need for recompilation!
  • I improved the codetorun.py script (and gave the fellow a proper name, epics_channels.py) which handles the initialization AND the availability of the channels;
  • On the Raspberry Pi, I created two init scripts, /etc/init.d/epics_server.sh and /etc/init.d/epics_channels.sh, which start at the end of the boot process with default runlevels; the former starts the softIOc process (epics itself), while the latter executes the constantly running epics_channels.py script; as they are services, they can be started/stopped with the usual sudo /etc/init.d/NAME start|stop|restart

 

As a result, as soon as the Raspberry Pi completes its boot process, the two beatnote channels are immediately available.

 

  10770   Tue Dec 9 16:06:46 2014 diegoSummaryGeneralDec 8 - Check Frequency Counter module

Quote:

Quote:

Quote:

Attached is the timeline for Frequency Offset Locking related activities. All activities will be done mostly in morning and early afternoon hours.

[Diego, Manasa]

We looked into the configuration and settings that the frequency counters (FC) and Domenica (the R pi to which the FCs talk to) were left at . After poking around for a few hours, we were able to readout the FC output and see it on StripTool as well.

We have made a list of modifications that should be done on Domenica and to the readout scripts to make the FC module automated and user-friendly.

I will prepare a user manual that will go on the wiki once these changes are made.

 

 I started working on the scripts/FOL directory (I did a backup before tampering around!):

  • I still need to make some serious polishing in the folder, and into the Raspberry Pi itself, in order to have a clean and understandable environment;
  • as of now, I created an single armFC.c program, which takes as arguments the device (/dev/hidraw0 for the X arm, and /dev/hidraw1 for the Y arm) and the value to write into the frequency counter (0x3 for initialization and 0x2 for actual use); hence, no more need for recompilation!
  • I improved the codetorun.py script (and gave the fellow a proper name, epics_channels.py) which handles the initialization AND the availability of the channels;
  • On the Raspberry Pi, I created two init scripts, /etc/init.d/epics_server.sh and /etc/init.d/epics_channels.sh, which start at the end of the boot process with default runlevels; the former starts the softIOc process (epics itself), while the latter executes the constantly running epics_channels.py script; as they are services, they can be started/stopped with the usual sudo /etc/init.d/NAME start|stop|restart

 

As a result, as soon as the Raspberry Pi completes its boot process, the two beatnote channels are immediately available.

 

 OUTDATED: see elog 10779

 

 Update and corrections:

 

  • I forgot to log that I added a udev rule in /etc/udev/rules.d/98-hidraw-permissions.rules in order to let the controls user access the devices without having to sudo all the time;
  • I updated the ~/.bashrc and /opt/epics/epics-euser-env.sh files to fix syntax errors and add some aliases we usually use;
  • since /etc/init.d/ doesn't support automatic respawn of processes, I purged the two scripts I did yesterday and added two lines to /etc/inittab. This works just as fine (I tried a couple of reboots to verify that) and the two processes now respawn automatically even if killed (and, I assume, if they die for any other reason)
  • Another thing I forgot: for the time being, during the cleanup, the Raspberry Pi works on the network share script directory. Once cleaning is done and everything is fixed, everything will run locally on the RPi, and the scripts/FOL directory on chiara will be used as backup/repository.
  10767   Tue Dec 9 00:30:27 2014 manasaSummaryGeneralDec 9 - Elaborate to do list

Quote:

Attached is the timeline for Frequency Offset Locking related activities. All activities will be done mostly in morning and early afternoon hours.

Elaborate to do list:

1. The FC module should be mounted on the IOO rack. Domenica has to be powered up appropriately to the rack power supply.

2. The fiber chassis needs to be built. This will hold all the fiber components and will sit inside the PSL enclosure.
Fiber connectors and fiber couplers need to be installed in the chassis. Attached is the cartoon sketch of layout in the chassis.

3. User guide for FC module (work in progress)

  10771   Tue Dec 9 16:07:16 2014 manasaSummaryGeneralDec 9 - FC module and fiber chassis

Quote:

Quote:

Attached is the timeline for Frequency Offset Locking related activities. All activities will be done mostly in morning and early afternoon hours.

Elaborate to do list:

1. The FC module should be mounted on the IOO rack. Domenica has to be powered up appropriately to the rack power supply.

2. The fiber chassis needs to be built. This will hold all the fiber components and will sit inside the PSL enclosure.
Fiber connectors and fiber couplers need to be installed in the chassis. Attached is the cartoon sketch of layout in the chassis.

3. User guide for FC module (work in progress)

1. FC module has been mounted on the IOO rack. The module gets it AC supply from the powerstrip already installed on the back side of the rack.

FCmodule.png

2. The fiber chassis has not been put together completely. We have still not received the front and back panels for the chassis; which is keeping me on hold. Diego is almost done with his housekeeping on Domenica. He will post an elog with all the details.

3. User guide for FC module (work in progress)

  12703   Wed Jan 11 19:20:23 2017 Max IsiUpdateSummary PagesDecember outage

The summary pages were not successfully generated for a long period of time at the end of 2016 due to syntax errors in the PEM and Weather configuration files.

These errors caused the INI parser to crash and brought down the whole gwsumm system. It seems that changes in the configuration of the Condor daemon at the CIT clusters may have made our infrastructure less robust against these kinds of problems (which would explain why there wasn't a better error message/alert), but this requires further investigation.

In any case, the solution was as simple as correcting the typos in the config side (on the nodus side) and restarting the cron jobs (on the cluster side, by doing `condor_rm 40m && condor_submit DetectorChar/condor/gw_daily_summary.sub`). Producing pages for the missing days will take some time (how to do so for a particular day is explained in the wiki https://wiki-40m.ligo.caltech.edu/DailySummaryHelp).

RXA: later, Max sent us this secret note:

However, I realize it might not be clear from the page which are the key steps. These are just running:

1) ./DetectorChar/bin/gw_daily_summary --day YYYYMMDD --file-tag some_custom_tag To create pages for day YYYYMMDD (the file-tag option is not strictly necessary but will prevent conflict with other instances of the code running simultaneously).

2) sync those days back to nodus by doing, eg: ./DetectorChar/bin/pushnodus 20160701 20160702

This must all be done from the cluster using the 40m shared account.
  12709   Thu Jan 12 23:22:34 2017 ranaUpdateSummary PagesDecember outage

Pages still not working: PEM and MEDM blank.

  • Committed existing MEDM grabbing scripts to SVN. Ran the cron job on megatron by hand. It grabs PNG files, but somehow its not getting into the summary pages.
  • Changed the MEDM grabbing scripts to use '/usr/bin/env'.
  • GW summary log files were numbering in the many thousands, so I moved everything over 320 days old into the OLD/ sub-directory using 'find . -type f -mtime +320 -exec mv {} OLD/ \;' (the semi-colon is needed)
  • Did apt-get upgrade on Megatron.
  • pinged Max
  • Stared at GWsumm docs to see if there's a clue about what (if anything) is wrong with the .ini file.
  12713   Fri Jan 13 14:33:00 2017 MAX (not Rana)UpdateSummary PagesDecember outage

PEM config file was also lacking a section named "summary", which is necessary for all parent tabs; this has now been solved. I have deactivated the MEDM pages because Praful's screencap script seemed to be broken (I should have logged this, I apologize).

Quote:

Pages still not working: PEM and MEDM blank.

  • Committed existing MEDM grabbing scripts to SVN. Ran the cron job on megatron by hand. It grabs PNG files, but somehow its not getting into the summary pages.
  • Changed the MEDM grabbing scripts to use '/usr/bin/env'.
  • GW summary log files were numbering in the many thousands, so I moved everything over 320 days old into the OLD/ sub-directory using 'find . -type f -mtime +320 -exec mv {} OLD/ \;' (the semi-colon is needed)
  • Did apt-get upgrade on Megatron.
  • pinged Max
  • Stared at GWsumm docs to see if there's a clue about what (if anything) is wrong with the .ini file.

 

  12435   Tue Aug 23 22:58:16 2016 KojiUpdateElectronicsDecoupling capacitor 101

What I suggested was:
- For most cases, power decoupling capacitors for the regulators should be ~100nF "high-K ceramic capacitors" + 47uF~100uF "electrolytic capacitors".
- For opamps, 100nF high-K ceramic should be fine, but you should consult with datasheets.
- Usually, you don't need to use tantalum capacitors for this purpose unless specified.
- Don't use film capacitors for power decoupling.

79XXs are less stable compared to 78XXs, and tend to become unstable depending on the load capacitance.
One should consult with the datasheet of each chip in order to know the proper capacitors values.
But also, you may need to tweak the capacitor value when necessary. Above recipe works most of the case.

  12437   Wed Aug 24 14:44:33 2016 PrafulUpdateElectronicsDecoupling capacitor 101

Do these look good for the ceramic capacitors? We're running low.

http://www.mouser.com/ProductDetail/Vishay-BC-Components/K104K15X7RF53L2/?qs=sGAEpiMZZMuMW9TJLBQkXmrXPxxCV7CRo6C15yUYAos%3d

Quote:

What I suggested was:
- For most cases, power decoupling capacitors for the regulators should be ~100nF "high-K ceramic capacitors" + 47uF~100uF "electrolytic capacitors".
- For opamps, 100nF high-K ceramic should be fine, but you should consult with datasheets.
- Usually, you don't need to use tantalum capacitors for this purpose unless specified.
- Don't use film capacitors for power decoupling.

79XXs are less stable compared to 78XXs, and tend to become unstable depending on the load capacitance.
One should consult with the datasheet of each chip in order to know the proper capacitors values.
But also, you may need to tweak the capacitor value when necessary. Above recipe works most of the case.

 

  12438   Wed Aug 24 19:37:55 2016 KojiUpdateElectronicsDecoupling capacitor 101

Yes

Interesting articles how they should only be used for power decoupling and not in the signal path.

http://www.edn.com/design/analog/4416466/Signal-distortion-from-high-K-ceramic-capacitors

http://www.edn.com/design/analog/4426318/More-about-understanding-the-distortion-mechanism-of-high-K-MLCCs

  7759   Wed Nov 28 23:18:35 2012 CharlesUpdatePEMDecreased RMS in Seismometers

The attached plots display RMS noise from various accelerometers and seismometers over the past 90 days. One can see how after the reinstallation of the seismometers in November, RMS from the GUR1Z and GUR1X channels decreases by a factor of about 100 from data in August. Additionally, the RMS over the course of the last 90 days has notably decreased in all instruments. In many cases, the RMS is only the result of inherent electronics noise, rather than from a signal.

  7762   Thu Nov 29 02:43:48 2012 AyakaUpdatePEMDecreased RMS in Seismometers

Quote:

The attached plots display RMS noise from various accelerometers and seismometers over the past 90 days. One can see how after the reinstallation of the seismometers in November, RMS from the GUR1Z and GUR1X channels decreases by a factor of about 100 from data in August. Additionally, the RMS over the course of the last 90 days has notably decreased in all instruments. In many cases, the RMS is only the result of inherent electronics noise, rather than from a signal.

The Image is replaced

[Den, Ayaka]

We found that seismometer was working and the calibration in the filter banks should have been wrong.
We turned off the all FM2 filter in RMS filter banks.

We also installed STS seismometer. It is under the BS. Now we have spectrum of three seismometers.
GUR1Xfilterbank.pngseismometers1129.pdf


 

RA: the above plot is kind of unreadable and useless. Please replace with something legible and put in some words about why there is a wrong filter, what exactly it is, etc., etc. etc. And why would you leave in a filter which is not supposed to be on? We might as well leave a few secretly broken chairs in the control room...

  7763   Thu Nov 29 09:58:06 2012 DenUpdatePEMDecreased RMS in Seismometers

Quote:

[Den, Ayaka]

We found that seismometer was working and the calibration in the filter banks should have been wrong.
We turned off the all FM2 filter in RMS filter banks.
 

We also installed STS seismometer. It is under the BS. Now we have spectrum of three seismometers;
 

RA: the above plot is kind of unreadable and useless. Please replace with something legible and put in some words about why there is a wrong filter, what exactly it is, etc., etc. etc. And why would you leave in a filter which is not supposed to be on? We might as well leave a few secretly broken chairs in the control room...

 First of all, STS-2 is in the end of X arm, GUR2 is under BS, GUR1 is in the end of Y arm.

BLRMS were small because we applied calibration from counts to um/s two times. In the past we had calibration in the RMS BP filter bank (vel2vel = FM2). Now we have calibration in the seismometer input filter bank so we can save calibrated _OUT channels.

  6625   Tue May 8 16:43:15 2012 JenneUpdateCDSDegenerate channels, potentially a big mess

Rana theorized that we're having problems with the MC error signal in the OAF model (separate elog by Den to follow) because we've named a channel "C1:IOO-MC_F", and such a channel already used to exist.  So, Rana and I went out to do some brief cable tracing.

MC Servo Board has 3 outputs that are interesting:  "DAQ OUT" which is a 4-pin LEMO, "SERVO OUT" which is a 2-pin LEMO, and "OUT1", which is a BNC->2pin LEMO right now.

DAQ OUT should have the actal MC_F signal, which goes through to the laser's PZT.  This is the signal that we want to be using for the OAF model.

SERVO OUT should be a copy of this actual MC_F signal going to the laser's PZT.  This is also acceptable for use with the OAF model.

OUT1 is a monitor of the slow(er) MC_L signal, which used to be fed back to the MC2 suspension.  We want to keep this naming convention, in case we ever decide to go back and feed back to the suspensions for freq. stabilization.

Right now, OUT1 is going to the first channel of ADC0 on c1ioo.  SERVOout is going to the 7th channel on ADC0.  DAQout is going to the ~12th channel of ADC1 on c1ioo.  OUT1 and SERVOout both go to the 2-pin LEMO whitening board, which goes to some new aLIGO-style ADC breakout boards with ribbon cables, which then goes to ADC0.  DAQout goes to the 4pin LEMO ADC breakout, (J7 connector) which then directly goes to ADC1 on c1ioo.

So, to sum up, OUT1 should be "adc0_0" in the simulink model, SERVOout should be "adc0_6" on the simulink model, and DAQout should be "adc1_12" (or something....I always get mixed up with the channel counting on 4pin ADC breakout / AA boards). 

In the current simulink setup, OUT1 (adc0_0) is given the channel name C1:IOO-MC_F, and is fed to the OAF model.  We need to change it to C1:IOO-MC_L to be consistent with the old regime.

In the current simulink setup, SERVOout (adc0_6) is given the channel name C1:IOO-MC_SERVO.  It should be called C1:IOO-MC_F, and should go to the OAF model.

In the current simulink setup,DAQout (~adc1_12) doesn't go anywhere.  It's completely not in the system.  Since the cable in the back of this AA / ADC breakout board box goes directly to the c1ioo I/O chassis, I don't think we have a degenerate MC_F naming situation.  We've incorrectly labeled MC_L as MC_F, but we don't currently have 2 signals both called MC_F.

Okay, that doesn't explain precisely why we see funny business with the OAF model's version of MCL, but I think it goes in the direction of ruling out a degenerate MC_F name.

Problem:  If you look at the screen cap, both simulink models are running on the same computer (c1ioo), so when they both refer to ADC0, they're really referring to the same physical card.  Both of these models have adc0_6 defined, but they're defined as completely different things.  Since we can trace / see the cable going from the MC Servo Board to the whitening card, I think the MC_SERVO definition is correct.  Which means that this Green_PH_ADC is not really what it claims to be.  I'm not sure what this channel is used for, but I think we should be very cautious and look into this before doing any more green locking.  It would be dumb to fail because we're using the wrong signals.

 

  15917   Fri Mar 12 19:44:31 2021 gautamUpdateLSCDelay line

I may want to use the delay line phase shifter in 1Y2 to allow remote actuation of the REFL11 demod phase (for the AO path, not the low bandwidth one). I had this working last Feb, but today, I am unable to remotely change the delay. @Koji, it would be great if you could fix this the next time you are in the lab - I bet it's a busted latch IC or some such thing. I did the non-invasive tests - cable is connected, control bits are changing (at least according to the CDS BIO indicators) and the switch controlling remote/local switching is set correctly. The local switching works just fine.

In the meantime, I will keep trying - I am unconvinced we really need the delay line.

  15927   Wed Mar 17 00:05:26 2021 gautamUpdateLSCDelay line BIO remote control

While Koji is working on the REFL 11 demod board, I took the opportunity to investigate the non-remote-controllability of the delay line in 1Y2, since the TTs have already been disturbed. Here is what I found today.

  1. First, I brought over the spare delay line from the rack Chiara sits in over to 1Y2. 
    • Connected a Marconi to the input, monitored a -3dB pickoff and the delay line output simultaneously on a 300MHz scope.
    • With the front panel selector set to "Internal", verified that local (i.e. toggling front panel switches) switchability seems to work 👍 
    • Set the front panel switch to "External", and connected the D25 cable from the BIO card in 1Y3 to the back panel of the delay line unit - found that I could not remotely change the delay 😒 
    • I thought it'd be too much of a coincidence if both delay lines have the same failure mode for the remote switching part only, so I decided to investigate further up the signal chain.
  2. BIO switching - the CDS BIO bit status MEDM screen seems to respond, indicating that the bits are getting set correctly in software at least. I don't know of any other software indicator for this functionality further down the signal processing chain. So it would seem the BIO card is not actually switching.
  3. The Contec DO cards don't actually source the voltage - they just provide a path for current to flow (or isolate said path). I checked that pin 12 of the rear panel D25 connector is at +5 V DC relative to ground as indicated in the schematic (see P1 connector - this connector isn't a Dsub, it is IDE24, so the mapping to the Dsub pins isn't one-to-one, but pin 23 on the former corresponds to pin 12 on the latter), suggesting that the pull up resistors have the necessary voltage applied to them.
  4. Made a little LED tester breakout board, and saw no swtiching when I toggled the status of some random bits.
  5. Noted that the bench power supply powering this setup (hacky arrangement from 2015 that never got unhacked) shows a current draw of 0A.
    • I am not sure what the quiescent draw of these boards is - the datasheet says "Power consumption: 3.3VDC, 450mA", but the recommended supply voltage is "12-24V DC (+/-10%)" not 3.3VDC, so not sure what to make of that.
    • To try and get some insight, I took one of the new Contec-32L-PE cards we got from near Jon's CDS test stand (I've labelled the one I took lest there be some fault with it in the future), and connected it to a bench supply (pin 18 = +15V DC, pin1 = GND). But in this condition, the bench supply reports 0A current draw.
  6. Ruled out the wrong cable being plugged in - I traced the cable over the cable tray, and seems like it is in fact connecting the BIO card in the c1lsc expansion chassis to the delay line.

So it would seem something is not quite right with this BIO card. The c1lsc expansion chassis, in which this card sits, is notoriously finicky, and this delay line isn't very high priority, so I am deferring more invasive investigation to the next time the system crashes.

* I forgot we have the nice PCB Contec tester board with LEDs - the only downside is that this board has D37 connectors on both ends whereas the delay line wants a D25, necessitating some custom ribbon cable action. But maybe there is a way to use this.

As part of this work, I was in various sensitive areas (1Y3, chiara rack, FE test stand etc) but as far as I can tell, all systems are nominal.

  11235   Wed Apr 22 11:48:30 2015 manasaSummaryGeneralDelay line frequency discriminator for FOL error signal

Since the Frequency counters have not been a reliable error signal for FOL PID loop, we will put together an analog delay line frequency dicriminator as an alternative method to obtain the beat frequency.

The configuration will be similar to what was done in elog 4254 in the first place.

For a delay line frequency dicriminator, the output at the mixer is proportional to cos(\theta_{b}) where \theta_{b} = 2 \pi f_{b}L/v

L - cable length asymmetry, fb - beat frequency and v - velocity of light in the cable.

The linear output signal canbe obtained for  0< \theta_{b}<\pi

For our purpose in FOL, if we would like to measure beat frequency over a bandwidth of 200MHz, this would correspond to a cable length difference of 0.5 m (assuming the speed of light in the coaxial cable is ~ 2x108m/s.

  11236   Wed Apr 22 14:56:18 2015 manasaSummaryGeneralDelay line frequency discriminator for FOL error signal

[Koji, Manasa]

Since the bandwidth of the fiber PD is ~ 1GHz, we could design the frequency discriminator to have a wider bandwidth (~ 500MHz). The output from the frequency discriminator could then be used to define the range setting of the frequency counter for readout or may be even error signal to the PID loop.

A test run for the analog DFD with cable length difference of 27cm gave a linear output signal with zero-crossing at ~206MHz.

Detailed schematic of the setup and plot (voltage vs frequency) will be updated shortly.

  11270   Mon May 4 10:21:09 2015 manasaSummaryGeneralDelay line frequency discriminator for FOL error signal

Attached is the schematic of the analog DFD and the plot showing the zero-crossing for a delay line length of 27cm. The bandwidth for the linear output signal obtained roughly matches what is expected from the length difference (370MHz) .

We could use a smaller cable to further increase our bandwidth. I propose we use this analog DFD to determine the range at which the frequency counter needs to be set and then use the frequency counter readout as the error signal for FOL.

 

  11272   Mon May 4 12:42:34 2015 manasaSummaryGeneralDelay line frequency discriminator for FOL error signal

Koji suggested that I make a cosine fit for the curve instead of a linear fit.

I fit the data to V(f) = A + B cos(2\pi f_{b}L/v) 
where L - cable length asymmetry (27 cm) , fb - beat frequency and v - velocity of light in the cable (2*10m/s)

The plot with the cosine fit is attached. 

Fit coefficients (with 95% confidence bounds):
       A =      0.4177  (0.3763, 0.4591)
       B =       2.941  (2.89, 2.992)

  11300   Mon May 18 14:46:20 2015 manasaSummaryGeneralDelay line frequency discriminator for FOL error signal

Measuring the voltage noise and frequency response of the Analog Delay-line Frequency Discriminator (DFD)

The schematic and an actual photo of the setup is shown below. The setup was checked to be physically sturdy with no loose connections or moving parts.

The voltage noise at the output of the DFD was measured using an SR785 signal analyzer while simultaneously monitoring the signal on an oscilloscope.

The noise at the output of the DFD was measured for no RF input and at several RF input frequencies including the zero crossing frequency and the optimum operating frequency of the DFD (20MHz).

The plot below show the voltage noise for different RF inputs to the DFD. It can be seen that the noise level is slightly lower at the zero crossing frequency where the amplitude noise is eliminated by the DFD.

I also did measurements to obtain the frequency response of the setup as the cable length difference has changed from the prior setup. The cable length difference is 21cm and the obtained linear signal at the output of the DFD extends over ~ 380MHz which is good enough for our purposes in FOL. A cosine fit to the data was done as before. //edit- Manasa: The gain of SR560 was set to 20 to obtain the data shown below//

Fit Coefficients (with 95% confidence bounds):
       a =     -0.8763  (-1.076, -0.6763)
       b =       3.771  (3.441, 4.102)

Data and matlab scripts are zipped and attached.

  11044   Tue Feb 17 16:44:04 2015 KojiUpdateLSCDelay line installed again

For tonight's experiment, I re-installed the delay line cable and changed the attenuation to 10dB for the 55MHz modulation.

I quickly locked the PLL and checked that the modulation is the ratio of the field strength between the worst (19ns) and best
case (28ns) is 31dB, that is ~35 times reduction.

  11059   Mon Feb 23 21:57:13 2015 KojiUpdateLSCDelay line installed again (experiment, round 1)

Last Wednesday we tried PRMI 3f modulation cancellation. Under the 3f modulation cancellation, the PRMI could not be locked
with REFL signals, and the PRCL signal was just barely sufficient to lock PRCL with help of AS55Q MICH.

- The PRCL signal level in REFL33 was reduced by factor of 20 compared with the conventional modulation setting.
=> The 3f modulation cancellation does not chage the level of 11/22MHz sidebands, it is expected that REFL33 signal
has no significant change of the signal level. But it does.  If we change the relative phase between the modulations
at 11 and 55MHz, the signal level is recovered by factor of 5. Therefore something related to 55MHz modulation
(55MHz x 22MHz, or 44MHz x 11MHz) was contributing more than -11MHzx22MHz.

- Under the 3f demodulation cancellation, MICH signal in the REFL ports were extremely weak and there was
no hope to use it for any feedback control.

- WIth the PRMI locking by REFL33->PRCL and AS55Q->MICH, the sensing matrix was measured. All of the REFL
ports however, showed extremely degenerate sensing matrix between MICH and PRCL.

This was enough confusing to us, and we didn't draw any useful information from these. Here are some ideas to
investigate what is happening in out optical and electrical system.

- One approach is to use as simple optical setup as possible to inspect our sensing systems. For example,
we may want to try PRX/PRY/XARM/YARM cavities to check the functions of the REFL diodes and qualitatively characterize
the sensing chain (Optical gain [W/m], noise level, demodulation phase) so that we can compare these with
an interferometer seinsing model.

- Another approach is to change the mdulation setting more freely and empirically try to find the characteristic
of our optical/electrical systems. e.g. change the relative modulation phase and/or 55MHz attenuation, and try to understand
how 11-22, 11-44, 22-55, 0-33 pairs are contributing the signal.

  11062   Tue Feb 24 23:39:16 2015 JenneUpdateLSCDelay line re-installed again

About 5-10 minutes ago I just put in the modulation cancellation setup according to the recipe in http://nodus.ligo.caltech.edu:8080/40m/11032

  11064   Wed Feb 25 04:59:47 2015 JenneUpdateLSCDelay line re-installed, measurements round 2

[Jenne, EricQ, Rana]

We spent this evening measuring and thinking about our 3f signals, and the effect of the modulation cancellation. 

I reinstalled the delay line box, and reduced the modulation depth of the 55MHz signal, so that we are in the state of modulation cancellation - there should be almost no power at 33MHz injected into the vacuum.  I carefully tuned the demod phase of the REFL 11, 33 and 55 MHz PDs, and locked the PRMI on REFL55 I&Q.  The signal in REFL 165 was very tiny, so as best as I could tell, the demod phase that Koji found last week was correct. 

Here is a little record of what the demodulation phases should be, for the "nominal" and "cancellation" configurations, so that we don't have to continually use the time machine.

  "Nominal" configuration 3f modulation cancellation
REFL 11 20 deg 76.0 deg (tuned to nearest 0.5 deg)
REFL 33 142.2 deg 120.3 deg (tuned to nearest 0.1 deg)
REFL 55 19 deg 173.0 deg (tuned to nearest 0.5 deg)
REFL 165 -172 deg 18 deg (same number as last week)
AS 55 -166.1 deg -111.1 deg (same number as last week)

Also, here is the locking recipe for REFL55 I&Q in the cancellation configuration:

PRMI, 3f cancellation, REFL55 I&Q MICH PRCL
Input Matrix acquire with -2*REFL55Q, then put matrix to -15*REFL55Q -12*REFL55I
Gain 3.0 -0.1
DoF trigger POP22I; 50 up, 0.5 down POP22I; 50 up, 0.5 down
FMs FM 4, 5 on FM 4, 5 on
FM trigger FM 1, 2, 3, 6, 9; 50 up, 0.5 down, 5 second wait FM 1, 2, 6, 9; 50 up, 0.5 down, 1 second wait
Normalization none none
Output matrix -1*ITMX, +1*ITMY 1*PRM

With this setup, we measured the sensing matrix.  MICH had an excitation at 370.123 Hz with 8,000 counts to -ITMX+ITMY (this is about 0.3nm for each ITM), and PRCL had an excitation at 404.123 Hz with 50 counts to PRM.  For tonight, here is a PDF of the peaks in DTT.  The data is saved in /users/Templates/LSC_error_spectra/SensMat_PRMI_24Feb2015.xml. 

SensMat_PRMI_24Feb2015.pdf


Rana has proposed to us an idea for why the REFL 33 signal should be dominated by the 55*22 contribution, rather than -11*22.  Eric is in the process of checking this out with a Mist model to see if it makes sense. Here's the gist:

Our Schnupp asymmetry is small (3.9cm, IIRC), so the transmission of the 11MHz signal out the dark port is small.  This means that the finesse of the PRC for 11MHz isn't so huge.  On the other hand, since 55MHz is a higher frequency, the transmission out the dark port is larger and is a closer match to the PRM transmission, so the finesse of the PRC for 55MHz is higher. 

Since the magnitudes of the fields at the reflection port are not changing significantly, our PDH signals are being created by the relative phase of something which is anti-resonant (ex. carrier or 22MHz for sideband lock) vs. something which is resonant (ex. 11MHz or 55MHz).  Since the finesse of the 55MHz signal is larger, the accumulated phase change is greater, so we expect a larger slope to our PDH signals that involve 55MHz as compared to those that use 11MHz.

If we are comparing the contributions between -11*22 and 55*22, they both include the anti-resonant 22MHz. So, the difference in the signal strengths comes directly from the difference in phase accumulation due to the variation in the dark port transmission.

EricQ had a thought, and while I have enough awake brain cells to report the thought, we're going to have to revisit it when more of our brains are awake.  In either case, the transmission through the dark port is small compared to the transmission of the ITMs, so why don't the ITMs dominate the finesse calculation, and thus are the 11MHz and 55MHz really getting that much of a difference in finesse?  To be checked out.

  11066   Wed Feb 25 12:16:27 2015 KojiUpdateLSCDelay line re-installed, measurements round 2

WHAT? WHAT? WHAT? It's obviously opposite.

If the reflectivity of the front mirror is fixed (=PRM reflectivity), the finesse increases when the reflectivity of the end
mirror (=Compond mirror reflectivity) increases. i.e. 11MHz has higher finesse, 55MHz has lower finesse.

{\cal F} = \frac{\pi \sqrt{r_{\rm PRM} r_{\rm COM}}}{1-r_{\rm PRM} r_{\rm COM}}

If the reflectivity of the front mirror is fixed, the amplitude gain of the cavity is higher when the reflectivity of the end mirror increases. i.e. 11MHz has higher gain, 55MHz has lower gain

g_{\rm PRM} = \frac{t_{\rm PRM}}{1-r_{\rm PRM} r_{\rm COM}}
 

Quote:

Our Schnupp asymmetry is small (3.9cm, IIRC), so the transmission of the 11MHz signal out the dark port is small.  This means that the finesse of the PRC for 11MHz isn't so huge.  On the other hand, since 55MHz is a higher frequency, the transmission out the dark port is larger and is a closer match to the PRM transmission, so the finesse of the PRC for 55MHz is higher. 

 

  11067   Wed Feb 25 14:18:28 2015 ranaUpdateLSCDelay line re-installed, measurements round 2

The Schnupp asymmetry is definitely not an important parameter (no need for Koji to explode). It only serves to give us a bigger Q phase signal slope, but is not significant for the I phase signals.

The main anomaly is that the REFL33 optical gain (W/m) seems to have been reduced so much by the phase and amplitude adjustment of the 55 MHz modulation signal. One guess is that the true 3f signal is being made not by the (2*f1 - (-f1)) beat, but by some higher order beat. In addition to the usual RF fields produced by the 2 modulations, we must consider that the sidebands on sidebands produce intermodulation fields just after the EOM and so the fields with which we interrogate the PRMI are more complicated.

Jenne's Optickle calculation today should show us what the sensing matrix contribution is from each pair of fields, so that we can have a sensing matrix signal budget.

 

  11045   Tue Feb 17 19:49:51 2015 KojiUpdateLSCDelay line un-installed again

The modulation setting was reverted.
Demod phase for REFL11/33/55/165 and AS55 were reverted to the previous numbers too.

  11069   Wed Feb 25 14:51:13 2015 JenneUpdateLSCDelay line un-installed again

And now I've removed the delay line, and am in the process of reverting the demod phases, etc.

  11070   Wed Feb 25 20:00:39 2015 JenneUpdateLSCDelay line un-installed again - sensing matrix comparisons

I have measured the sensing matrix for the PRMI at the REFL photodiodes for both the nominal configuration and the 33MHz cancellation configuration.  The nominal configuration measurements do not compare well with those from November (http://nodus.ligo.caltech.edu:8080/40m/10701) which makes me unhappy no.  Both sets of nominal config reported below are from today, after tuning the demod phases and making sure the MICH and PRCL loops looked the same as yesterday (esp. overall gain).  The cancellation config data is from last night.

Note that the magnitude for each photodiode is referred to its own "PD counts".  Since the electronics are different for each PD, and that is not taken into account here, you cannot directly compare an element from one PD to an element from another PD.  What you can do (which is most of what we need right now) is compare all the different measurements for a single photodiode.

PRCL Sensing elements 33 MHz cancellation, REFL55 I&Q lock Nominal, REFL55I&Q lock Nominal, REFL33I&Q lock
  Mag [PD counts / m] Phase [deg] Mag [PD counts / m] Phase [deg] Mag[PD counts / m] Phase [deg]
REFL 11 3.0e13 0.05 4.2e13 0.1 2.9e13 0.1
REFL 33 1.1e11 3.4 1.8e12 0.25 1.2e12 0.3
REFL 55 1.8e10 2.1 1.4e11 4.8 9.3e10 4.1
REFL 165 7.0e9 15.5 6.3e11 0.5 4.2e11 0.9

 

MICH Sensing elements 33MHz cancellation, REFL55 I&Q lock Nominal, REFL55 I&Q lock Nominal, REFL33 I&Q lock
  Mag [PD counts / m] Phase [deg] Mag [PD counts / m] Phase [deg] Mag [PD counts / m] Phase [deg]
REFL 11 3.0e12 2.8 4.1e12 3.0 2.9e12 3.3
REFL 33 1.1e10 3.7 1.7e11 3.5 1.2e11 3.9
REFL 55 2.1e9 30.3 1.4e10 27.7 1.1e10 30.2
REFL165 6.4e8 24.4 6.3e10 21.0 4.5e10 23.0

So, what I'm apparently seeing is that the magnitudes of the sensing matrix signals that are made using 55MHz (i.e. everything but REFL11) change when we go into the cancellation configuration, but the phases of the sensing elements do not change significantly.  Also, I am apparently seeing that REFL11 and REFL33 only have about 3 degrees of separation between the MICH and PRCL signals no matter what configuration is used.  This doesn't make a lot of sense, since we know that we can lock robustly on REFL33I&Q (it's been sitting there happily as I write this elog), so it seems crazy that we could actually be so degenerate.  Also, at the bottom of the elog that I wrote in November 2014, I show a sensing matrix where both REFL11 and REFL33 have about 45 degrees of separation between the MICH and PRCL signals.

I don't think I'm doing anything too crazy here, particularly with the phase.  For a given PD and given DoF, I find the magnitude of the peaks of the I and Q signals, and just do atan2(Q-signal, I-signal)*180/pi, and those are the numbers that go in the phase columns above. 


Before taking my measurements, I tuned up the demod phases for the PRMI-only case.  I think REFL11 may have previously been tuned for CARM when the arms were held with ALS, but I don't really recall.  Anyhow, now all 4 REFL PDs are tuned for PRMI-only.

This was done while the PRMI was locked with REFL 55 I&Q. 

EDIT, 26Feb2015: Last night I mixed up the REFL11 and REFL33 new demod phases.  Bold are the corrected version.  Also, note that REFL33 was formerly tuned for PRCL in PRFPMI, which may be why it changed by ~10 degrees.

  Old demod phase [deg] New demod phase [deg]
REFL11 20 131.7 +/- 0.1   74.7 +/- 0.1
REFL33 142.2 74.7 +/- 0.1    131.7 +/- 0.1 
REFL55 19

15.3 +/- 0.3

REFL165 -172 -170.0 +/- 0.2

Here's the recipe for locking REFL 55 I&Q in the nominal modulation configuration.  It's the same as the REFL33 I&Q lock that I was using today, except that for the REFL33 version, the matrix elements are both unity.

PRMI REFL55 I&Q, nominal configuration MICH PRCL

Input Matrix

36*REFL55Q 12*REFL55I
Gain 5.0 -0.028
DoF trigger POP22I; 50 up, 0.5 down POP22I; 50 up, 0.5 down
FMs FM 4, 5 on FM 4, 5 on
FM trigger FM 2, 3, 6, 9; 50 up, 0.5 down, 5 second wait FM 1, 2, 6, 8, 9; 50 up, 0.5 down, 1 second wait
Normalization none none
Output matrix -1*ITMX, +1*ITMY 1*PRM

 

  4736   Wed May 18 07:13:00 2011 SureshUpdateRF SystemDemod board measurements

I measured the amplitude and phase imbalances of the demod boards which have been modified.  This is just a basic health check.  We hope to use the script that Kiwamu is developing for a more accurate test.  The script can also use these measurements as a sanity check.  POP110  requires some further attention. 

Demod_Board_measurements.png

 

The RF distribution box outputs corresponding to the demod board (eg. AS55_LO --> AS55_demod) were used as LO sources.  The RF signal was generated with a Marconi and held a kHz away from the LO frequency.  The amplitude and phase unbalance were measured with SR785.  The RF Power meter was used to check the LO power in each case.

 

 

  4755   Fri May 20 05:41:22 2011 SureshUpdateRF SystemDemod board measurements

The POP110 board which had the large Amplitude and Phase unbalances was examined today.  It turned out that there was some stray solder which had connected the Sum port of the PSCQ-2-120 splitter to its body (ground).  After I removed that the amplitude unbalance was 0.3dB however the phase was 105deg.  The phase reduced to 90 deg only if the power on the splitter is around 19 dBm.  So removed the AT1 (10dB attenuator) and the phase unbalance dropped to 91 deg.  However this is not a sustainable solution as the ERA-5 max output is about 19.5 dBm.

As this is a side band power monitor (and not a length sensing RFPD), we can make do with a poorer phase.  I will therefore replace the AT1 and adjust the residual phase with cable delay lines.  

Quote:

I measured the amplitude and phase imbalances of the demod boards which have been modified.  This is just a basic health check.  We hope to use the script that Kiwamu is developing for a more accurate test.  The script can also use these measurements as a sanity check.  POP110  requires some further attention. 

Demod_Board_measurements.png

 

The RF distribution box outputs corresponding to the demod board (eg. AS55_LO --> AS55_demod) were used as LO sources.  The RF signal was generated with a Marconi and held a kHz away from the LO frequency.  The amplitude and phase unbalance were measured with SR785.  The RF Power meter was used to check the LO power in each case.

 

 

 

  15834   Tue Feb 23 00:10:05 2021 gautamUpdateGeneralDemod char part 1

I measured the conversion efficiencies for all the RFPD demod boards except the POP port ones. An RF source was used to drive the PD input on the demod board, one at a time, and the I/F outputs were monitored on a 300 MHz oscilloscope. The efficiency is measured as the percentage ratio V_IF / V_RF. 

I will upload the full report later, but basically, the numbers I measured today are within 10% of what I measured in 2017 when I previously did such a characterization. The orthogonality also seems fine. 

I believe I restored all the connections at 1Y2 correctly, and I can lock POX/POY and PRMI on 1f signals after my work. I will do the noise characterization tomorrow - but I think this test already rules out any funkiness with the demod setup (e.g. non orthogonality of the digitized "I" and "Q" signals). The whitening part of the analog chain remains untested.

Quote:

But I would still bet on demod chain funniness


Update 2/23 1215: I've broken up the results into the demod boards that do not (Attachment #1) and do (Attachment #2) have a D040179 preamp installed. Actually, the REFL11 AO path also has the preamp installed, but I forgot to capture the time domain data for those channels. The conversion efficiency inferred from the scope was ~5.23 V/V, which is in good agreement with what I measured a few years ago.

  • The scope traces were downloaded.
  • The resulting X/Y traces are fitted with ellipses to judge the gain imbalance and orthogonality.
  • The parameter phi is the rotation of the "bounding box" for the fitted ellipses - if the I and Q channels are exactly orthogonal, this should be either 0 or 90 degrees. There is significant deviation from these numbers for some of the demodulators, do we want to do something about this? Anyways, the REFL11 and AS55 boards, which are used for PRMI locking, report reasonable values. But REFL165 shows an ellipse with significant rotation. This is probably how the CDS phase rotator should be tuned, by fitting an ellipse to the digitized I/Q data and then making the bounding box rotation angle 0 by adjusting the "Measured Diff" parameter.
  • The gain imbalance seems okay across the board, better than 1dB.
  • The POX and POY traces are a bit weird, looks like there is some non-trivial amount of distortion from the expected pure sinusoid.
  • I measured the LO input levels going into each demod board - they all lie in the range 2-3dBm (measured with RF power meter), which is what is to be expected per the design doc. The exception the the 165 MHz LO line, which was 0.4 dBm. So this board probably needs some work. 
  • As I mentioned earlier, the conversion efficiencies are consistent with what I measured in 2017. I didn't break out the Eurocards using an extender and directly probe the LO levels at various points, but the fact that the conversion efficiencies have not degraded and the values are consistent with the insertion loss of various components in the chain make me believe the problem lies elsewhere. 

For completeness, I will measure the input terminated I/F output noise levels later today. Note also that my characterization of the optical modulation profile did not reveal anything obviously wrong (to me at least). 

  15839   Wed Feb 24 11:53:24 2021 gautamUpdateGeneralDemod char part 2

I measured the noise of the I/F outputs of all the LSC demodulators. I made the measurement in two conditions, one with the RF input to the demodulators terminated with 50 ohms to ground, and the other with the RFPD plugged in, but the PSL shutter closed (so the PD dark noise was the input to the demodulator). The LO input was driven at the nominal level for all measurements (2-3 dBm going in to the LO input, measured with the RF power meter, but I don't know what the level reaching the mixer is, because there is a complicated chain of ERA amplifiers and attenuators that determine what the level is). 

As in the previous elog, I have grouped the results into boards that do not (Attachment #1) and do (Attachment #2) have the low noise preamp installed. The top row is for the "Input terminated" measurements, while the bottom is with the RFPD plugged in, but dark. I think not a single board shows the "expected" noise performance for both I and Q channels. In the case where the preamp isn't installed and assuming the mixer is being driven with >17dBm LO, we expect the mixer to demodulate the Johnson noise of 50 ohms, which would be ~1nV/rtHz, and so with the SR785, we shouldn't measure anything in exceess of the instrument noise floor. With the low noise preamp installed, the expected output noise level is ~10nV/rtHz, which should just about be measurable (I didn't use any additional Low Noise front end preamp for these measurements). The AS55_I channel shows noise consistent with what was measured in 2017 after it was repaired, but the Q channel shows ~twice the noise. It seemed odd to me that the Q channels show consistently higher noise levels in general, but I confirmed that the SR785 channel 2 did not show elevated instrument noise at least when terminated with 50 ohms, so seems like a real thing.

While this is clearly not an ideal state of operation, I don't see how this can explain the odd PRMI sensing.

Quote:

For completeness, I will measure the input terminated I/F output noise levels later today. Note also that my characterization of the optical modulation profile did not reveal anything obviously wrong (to me at least). 

  15840   Wed Feb 24 12:11:08 2021 gautamUpdateGeneralDemod char part 3

I did the characterization discussed at the meeting today.

  1. RF signal at 100 Hz offset from the LO frequency was injected into the PD input on the demod boards.
  2. The digitized CDS channels were monitored. I chose to look at the C1:LSC-{PD}_I_OUT and C1:LSC-{PD}_Q_OUT channels. This undoes the effect of the analog whitening, but is before the digital phase rotation.
  3. Attachments #1 and Attachments #2 are for the case where the analog whitening is not engaged, white Attachments #3 and Attachments #4 are for when the whitening is engaged, and they look the same (as they should), which rules out any crazy mismatch between the analog filter and the digital dewhitening filter.
  4. I have absorbed the flat whitening gain applied to the various PDs in the cts/V calibration indicated on these plots. So the size of the ellipse is proportional to the conversion gain.

I think this test doesn't suggest anything funky in the analog demod/whitening/AA/digitization chain. We can repeat this process after the demod boards are repaired and use the angle of rotation of the ellipse to set the "D" parameter in the CDS phase rotator part, I didn't do it today.

  9103   Wed Sep 4 17:22:09 2013 JenneUpdateLSCDemod phases for RFPDs

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

 

  10280   Mon Jul 28 10:42:43 2014 NichinUpdateElectronicsDemodulator board's characterization

 I used vector fitting to fit the transfer functions between RF input and PD RF MON of demodulator boards. These fittings can certainly do a lot better on LISO, but for the time being I will assume these to be good enough and change the main PDFR scripts to calibrate out this factor and get a decent reading of PD transimpedance. Then it will just be a matter of changing the transfer function parameters. A lot of work needs to be done on the PDFR interface and plot features.

Attached: The plots showing data and fits.

ELOG V3.1.3-