40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 255 of 339  Not logged in ELOG logo
ID Date Author Type Categoryup Subject
  15162   Tue Jan 28 08:26:53 2020 ranaFrogsPEMshaking

https://breakthrough.caltech.edu/magazine/2019-aug/#article-Listening-with-Light

  15313   Fri Apr 24 00:26:59 2020 ranaSummaryPEML.A. EQ from Tuesday night
Attachment 1: April22-EQ.pdf
April22-EQ.pdf
  15445   Wed Jul 1 12:50:40 2020 gautamUpdatePEMMC1 accelerometers plugged in

I re-connected the 3 accelerometers located near the MC1/MC3 chamber. It was a bit tedious to get the cabling sorted - I estimate the cable is ~80m long, and the excess length had to be wound around a spool (see Attachment #1), which wasn't really a 1 person job. It's neat-ish for now, but I'm not entirely satisfied. I think we should get shorter cables (~20m), and also mount the pre-amp/power units in a rack instead of leaving it on the floor. The pre-amp settings are x100 for all three channels. The MC2 channels are powered, but are unconnected to the seismometers - it was too tedious to unroll the other spool yesterday. Apart from this, the cable for the "Z" channel had to be re-seated in the strain relief clamp.

I did not enable any of the CDS filters that convert the raw signal into physical units, so for now, these channels are just recording raw counts.

Update 7pm: the spectra in the current config are here - not sure what to make of the MC2_Z channel appearing to show lower noise?

Update July 13 2020 430pm: This afternoon, I hooked up the MC2 accelerometer channels too...

Attachment 1: IMG_8617.JPG
IMG_8617.JPG
Attachment 2: IMG_8616.JPG
IMG_8616.JPG
  15634   Mon Oct 19 15:40:02 2020 KojiUpdatePEMAlaska EQ M7.5

Alaska M7.5 20:54UTC https://earthquake.usgs.gov/earthquakes/eventpage/us6000c9hg/executive

I looked at the suspensions. The watchdogs have not been tripped.

IMC was locked but continually shaken. (and occasional unlock)

  15642   Fri Oct 23 19:01:57 2020 KojiSummaryPEMPSL Particle Counter kit removed from the table

The particle counter on the 40m PSL was removed. The package was made together with the OMC lab particle counter (see the packing list below).

The kit was picked up by Radhika for a python code to read out the numbers.

=== Packing List ===

  • MET ONE 227A particle counter
    • used at the 40m. It has the particle reading and the temperature reading.
  • Power supply adapter (AC/DC) for 227A
    • Caution: It is not compatible with GT-321.
  • MET ONE GT-321
    • I found another type of particle counter in West Bridge.
  • Power supply adapter (AC/DC) for GT-321. (Labeled "for GT-321")
    • Caution: It is not compatible with 227A.
  • DB9 cable for GT-321
  • Air Filter G3111
    • When you run a particle counter attach this filter instead of the dust collecting cup to keep the air in take of the particle counter clean. This should keep the particle level down to zero.
       
Attachment 1: P_20201022_173529.jpg
P_20201022_173529.jpg
Attachment 2: P_20201022_173419.jpg
P_20201022_173419.jpg
  15863   Thu Mar 4 15:48:26 2021 KojiSummaryPEMWatchdog tripped, Optics damped back

EQs seen on Summary pages
https://nodus.ligo.caltech.edu:30889/detcharsummary/day/20210304/pem/seismic_blrms/

  16214   Fri Jun 18 14:53:37 2021 AnchalSummaryPEMTemperature sensor network proposal

I propose we set up a temperature sensor network as described in attachment 1.

Here there are two types of units:

  • BASE-GATEWAY
    • Holds the processor to talk to the network through Modbus TCP/IP protocol.
    • This unit itself has a temperature sensor in it. It is powered by a power adaptor or PoE from the switch.
    • Each base unit can have at max 2 extended temperature probes ENV-TEMP.
  • ENV-TEMP
    • This is just a temperature probe with no other capabilities.
    • It is powered via PoE from the BASE-GATEWAY unit.

Proposal is

  • to put 2 ENV-TEMP sensors (#1 and #2) along the Y-arm at the end and midway. These are powered and read through a BASE-GATEWAY (#A) at the vertex. The BASE-GATEWAY (#A) will serve as temperature sensor for the vertex.
  • We put one ENV-TEMP(#3) at the X-end powered and read through by another BASE-GATEWAY (#B) at the midpoint of X-arm.
  • Both BASE-GATEWAY are connected by ethernet cables to the network switch. That's it.

These sensors can be configured over network by going to their assigned IP addresses. I'm not sure at the moment how to configure the dB files to get them to write on slow EPICS channels.

We will have an unused port on the BASE-GATEWAY (#B) which can be used to run another temperature sensor, maybe at an important rack, PSL table or somewhere else.

In future, if more sensors are required, there are expansion (network switch like) options for BASE-GATEWAY or daisy-chain options for the probes.



Edit Fri Jun 18 16:28:13 2021 :

See this [wiki page](https://wiki-40m.ligo.caltech.edu/Physical_Environment_Monitoring/Thermometers) for updated plan and final quote.

Attachment 1: 40mTempSensors.pdf
40mTempSensors.pdf
  16323   Mon Sep 13 17:05:04 2021 TegaSummaryPEMInfrasensing temperature sensor modbus configuration

Anchal mentioned it would be good to put more details about how I arrived at the values needed to configure the modbus drive for the temperature sensor, since this information is not in the manual and is hard to find on the internet, so here is a breakdown.

So the generic format is:

drvAsynIPPortConfigure("<TCP_PORT_NAME>","<UNIT_IP_ADDRESS>:502",0,0,1)
modbusInterposeConfig("<TCP_PORT_NAME>",0,5000,0)
drvModbusAsynConfigure("<PORT_NAME>","<TCP_PORT_NAME>",<slaveAddress>,<modbusFunction>,<modbusStartAddress>,<modbusLength>,<dataType>,<pollMsec>,<plcType>)

which in our case become:

drvAsynIPPortConfigure("c1pemxendtemp","192.168.113.240:502",0,0,1)
modbusInterposeConfig("c1pemxendtemp",0,5000,0)
drvModbusAsynConfigure("C1PEMXENDTEMP","c1pemxendtemp",0,4,199,2,0,1000,"ServerCheck")

As can be seen, the parameters of the first two functions "drvAsynIPPortConfigure" and "modbusInterposeConfig" are straight forward, so we restrict our discussion to the case of third function "drvModbusAsynConfigure". Well, after hours of trolling the internet, I was able to piece together a coherent picture of what needs doing and I have summarised them in the table below.

 

drvModbusAsynConfigure

Once the asyn IP or serial port driver has been created, and the modbusInterpose driver has been configured, a modbus port driver is created with the following command:

drvModbusAsynConfigure(portName,                # used by channel definitions in .db file to reference this unit)
                       tcpPortName,             # reference to portName created with drvAsynIPPortConfigure command
                       slaveAddress,            # 
                       modbusFunction,          # 
                       modbusStartAddress,      # 
                       modbusLength,            # length in dataType units
                       dataType,                # 
                       pollMsec,                # how frequently to request a value in [ms]
                       plcType);                #

drvModbusAsynConfigure command
Parameter Data type Description
portName string Name of the modbus port to be created.
 
tcpPortName string Name of the asyn IP or serial port previously created.

tcpPortName = { 192.168.113.240:502192.168.113.241:502192.168.113.242:502 }
 
slaveAddress int The address of the Modbus slave. This must match the configuration of the Modbus slave (PLC) for RTU and ASCII. For TCP the slave address is used for the "unit identifier", the last field in the MBAP header. The "unit identifier" is ignored by most PLCs, but may be required by some.

ServersCheck API ignores this value, as confirmed with pymodbus query, so set to default value: 
slaveAddress = 0
 
modbusFunction int

modbus supports the following 8 Modbus function codes:

Modbus Function Codes
Access Function description Function code
Bit access Read Coils 1
Bit access Read Discrete Inputs 2
Bit access Write Single Coil 5
Bit access Write Multiple Coils 15
16-bit word access Read Input Registers 4
16-bit word access Read Holding Registers 3
16-bit word access Write Single Register 6
16-bit word access Write Multiple Registers 16
modbusStartAddress int Start address for the Modbus data segment to be accessed.
(0-65535 decimal, 0-0177777 octal).

Modbus addresses are specified by a 16-bit integer address. The location of inputs and outputs within the 16-bit address space is not defined by the Modbus protocol, it is vendor-specific. Note that 16-bit Modbus addresses are commonly specified with an offset of 400001 (or 300001). This offset is not used by the modbus driver, it uses only the 16-bit address, not the offset.

For ServersCheck, the offset is "30001", so that

modbusStartAddress = 30200 - 30001 = 199

modbusLength int The length of the Modbus data segment to be accessed.
This is specified in bits for Modbus functions 1, 2, 5 and 15.
It is specified in 16-bit words for Modbus functions 3, 4, 6 and 16.
Length limit is 2000 for functions 1 and 2, 1968 for functions 5 and 15,
125 for functions 3 and 4, and 123 for functions 6 and 16.

ServersCheck uses two's complement 32-bits word (with big-endian byte order & little-endian word order) format to store floating-point data, as confirmed with pymodbus query, so that:

modbusLength = 2
 
modbusDataType int The modbusDataType is used to tell the driver the format of the Modbus data. The driver uses this information to convert the number between EPICS and Modbus. Data is transferred to and from EPICS as epicsUInt32, epicsInt32, and epicsFloat64 numbers.

Modbus data type:
0 = binary, twos-complement format
1 = binary, sign and magnitude format
2 = BCD, unsigned
3 = BCD, signed

Some Modbus devices (including ServersCheck) use floating point numbers, typically by storing a 32-bit float in two consecutive 16-bit registers. This is not supported by the Modbus specification, which only supports 16-bit registers and single-bit data. The modbus driver does not directly support reading such values, because the word order and floating point format is not specified.

Note that if it is desired to transmit BCD numbers untranslated to EPICS over the asynInt32 interface, then data type 0 should be used, because no translation is done in this case. 

For ServersCheck, we wish to transmit the untranslated data, so:

modbusDataType = 0
 
pollMsec int Polling delay time in msec for the polling thread for read functions.
For write functions, a non-zero value means that the Modbus data should
be read once when the port driver is first created.

ServersCheck recommends setting sensor polling interval between 1-5 seconds, so we can try:

pollMsec = 1000
 
plcType string Type of PLC (e.g. Koyo, Modicon, etc.).
This parameter is currently used only to print information in asynReport.
In the future it could be used to modify the driver behavior for a specific PLC.

plcType = "ServersCheck"
 

 

Useful links

https://nodus.ligo.caltech.edu:8081/40m/16214

https://nodus.ligo.caltech.edu:8081/40m/16269

https://nodus.ligo.caltech.edu:8081/40m/16270

https://nodus.ligo.caltech.edu:8081/40m/16274

 

http://manuals.serverscheck.com/InfraSensing_Sensors_Platform.pdf

http://manuals.serverscheck.com/InfraSensing_Modbus_manualv5.pdf

https://community.serverscheck.com/discussion/comment/7419#Comment_7419

 

https://wiki-40m.ligo.caltech.edu/CDS/SlowControls

https://www.slac.stanford.edu/grp/ssrl/spear/epics/site/modbus/modbusDoc.html#Creating_a_modbus_port_driver

 

https://github.com/riptideio/pymodbus

 

https://en.wikipedia.org/wiki/Modbus

https://deltamotion.com/support/webhelp/rmctools/Communications/Ethernet/Supported_Protocols/Ethernet_Modbus_TCP.htm

  16329   Tue Sep 14 17:19:38 2021 PacoSummaryPEMExcess seismic noise in 0.1 - 0.3 Hz band

For the past couple of days the 0.1 to 0.3 Hz RMS seismic noise along BS-X has increased. Attachment 1 shows the hour trend in the last ~ 10 days. We'll keep monitoring it, but one thing to note is how uncorrelated it seems to be from other frequency bands. The vertical axis in the plot is in um / s

Attachment 1: SEIS_2021-09-14_17-33-12.png
SEIS_2021-09-14_17-33-12.png
  16331   Tue Sep 14 19:12:03 2021 KojiSummaryPEMExcess seismic noise in 0.1 - 0.3 Hz band

Looks like this increase is correlated for BS/EX/EY. So it is likely to be real.

Comparison between 9/15 (UTC) (Attachment 1) and 9/10 (UTC) (Attachment 2)

Attachment 1: C1-ALL_393F21_SPECTRUM-1315699218-86400.png
C1-ALL_393F21_SPECTRUM-1315699218-86400.png
Attachment 2: C1-ALL_393F21_SPECTRUM-1315267218-86400.png
C1-ALL_393F21_SPECTRUM-1315267218-86400.png
  16416   Wed Oct 20 11:16:21 2021 AnchalSummaryPEMParticle counter setup near BS Chamber

I have placed a GT321 particle counter on top of the MC1/MC3 chamber next to the BS chamber. The serial cable is connected to c1psl computer on 1X2 using 2 usb extenders (blue in color) over the PSL enclosure and over the 1X1 rack.

The main serial communication script for this counter by Radhika is present in 40m/labutils/serial_com/gt321.py.

A 40m specific application script is present in the new git repo for 40m scripts, in 40m/scripts/PEM/particleCounter.py. Our plan is to slowly migrate the legacy scripts directory to this repo overtime. I've cloned this repo in the nfs shared directory at /opt/rtcds/caltech/c1/Git/40m/scripts which makes the scripts available at all computers and keep them upto date in all computers.

The particle counter script is running on c1psl through a systemd service, using service file 40m/scripts/PEM/particleCounter.service. Locally in c1psl, /etc/systemd/system/particleCounter.service is symbollically linked to the file in the file.

Following channels for particle counter needed to be created as I could not find any existing particle counter channels.

[C1:PEM-BS_PAR_CTS_0p3_UM]
[C1:PEM-BS_PAR_CTS_0p5_UM]
[C1:PEM-BS_PAR_CTS_1_UM]
[C1:PEM-BS_PAR_CTS_2_UM]
[C1:PEM-BS_PAR_CTS_5_UM]

These are created from 40m/softChansModbus/particleCountChans.db database file. Computer optimus is running a docker container to serve as EPICS server for such soft channels. To add or edit channels, one just need to add new database file or edit database files in thsi repo and on optimus do:

controls@optimus|~> sudo docker container restart softchansmodbus_SoftChans_1
softchansmodbus_SoftChans_1

that's it.

I've added the above channels to /opt/rtcds/caltech/c1/chans/daq/C0EDCU.ini to record them in framebuilder. Starting from 11:20 am Oct 20, 2021 PDT, the data on these channels is from BS chamber area. Currently the script is running continuosly, which means 0.3u particles are sampled every minute, 0.5u twice in 5 minutes and 1u, 2u, and 5u particles are sampled once in 5 minutes. We can reduce the sampling rate if this seems unncessary to us.

Attachment 1: PXL_20211020_183728734.jpg
PXL_20211020_183728734.jpg
  16420   Thu Oct 21 11:41:31 2021 AnchalSummaryPEMParticle counter setup near BS Chamber

The particle count channel names were changes yesterday to follow naming conventions used at the sites. Following are the new names:

C1:PEM-BS_DUST_300NM
C1:PEM-BS_DUST_500NM
C1:PEM-BS_DUST_1000NM
C1:PEM-BS_DUST_2000NM
C1:PEM-BS_DUST_5000NM
 

The legacy count channels are kept alive with C1:PEM-count_full copying C1:PEM-BS_DUST_1000NM channel and C1:PEM-count_half copying C1:PEM-BS_DUST_500NM channel.

Attachment one is the particle counter trend since 8:30 am morning today when the HVAC wokr started. Seems like there was some peak particle presence around 11 am. The particle counter even counted 8 counts of particles size above 5um!

 

Attachment 1: ParticleCountData20211021.pdf
ParticleCountData20211021.pdf
  16421   Thu Oct 21 15:22:35 2021 ranaSummaryPEMParticle counter setup near BS Chamber

SVG doesn't work in my browser(s). Can we use PDF as our standard for all graphics other than photos (PNG/JPG) ?

  16422   Thu Oct 21 15:24:35 2021 ranaSummaryPEMParticle counter setup near BS Chamber

rethinking what I said on Wednesday - its not a good idea to put the particle counter on a vac chamber with optics inside. The rumble from the air pump shows up in the acoustic noise of the interferometer. Let's look for a way to mount it near the BS chamber, but attached to something other than vacuum chambers and optical tables.

Quote:

I have placed a GT321 particle counter on top of the MC1/MC3 chamber next to the BS chamber.

 

  16423   Fri Oct 22 17:35:08 2021 Ian MacMillanSummaryPEMParticle counter setup near BS Chamber

I have done some reading about where would be the best place to put the particle counter. The ISO standard (14644-1:2015) for cleanrooms is one every 1000 m^2 so one for every 30m x 30m space. We should have the particle counter reasonably close to the open chamber and all the manufactures that I read about suggest a little more than 1 every 30x30m. We will have it much closer than this so it is nice to know that it should still get a good reading. They also suggest keeping it in the open and not tucked away which is a little obvious. I think the best spot is attached to the cable tray that is right above the door to the control room. This should put it out of the way and within about 5m of where we are working. I ordered some cables to route it over there last night so when they come in I can put it up there. 

  16503   Mon Dec 13 15:05:47 2021 TegaUpdatePEMgit repo for temp sensor and sus medm

[temperature sensor]

git repo: https://git.ligo.org/40m/tempsensor.git

todo

Update the temp sensor channels to fit with cds format, ie. "C1:PEM-TEMP_EX", "C1:PEM-TEMP_EY", "C1:PEM-TEMP_BS"

- Use FLOAT32_LE data format for the database file (/cvs/cds/caltech/target/c1pem1/tempsensor/C1PEMaux.db) to create the new channels.

- Keep the old datadase code and channels so we can compare with new temp channels afterwards. Also we need a 1-month overlap b4 deleting the old channels.

 

[sus medm screen]

git repo: https://git.ligo.org/40m/susmedmscreen.git

todo (from talk with Koji)

- Link stateword display to open "C1CDS_FE_STATUS.adl"

- Damp filter and Lock filter buttons should open a 3x1 filter screen so that the 6 filters are opened by 2 buttons compared to the old screen that has 3 buttons connected to 2X1 filter screen

- Make the LOCKIN signla modulation flow diagramlook more like the old 40m screen since that is a better layout

- Move load coefficient button to top of sus medm screen (beside stateword)

- The rectangular red outline around the oplev display is confusing and needs to be modified for clarity

- COMM tag block should not be 3D as this suggests it is a button. Make it flat and change tag name to indicate individual watchdog control as this better reflect its functionality. Rename current watchdog switch to watchdog master is it does what the 5 COMM switches do at once.

- Macro pass need to be better documented so that when we call the sus screens from locations other than sitemap, we should know what macro variables to pass in, like DCU_ID etc.

- Edit sitemap.adl to point only to the new screens. Then create a button on the new screen that points to the old screen. This way, we can still access the old screen without clogging sitemap.

- Move the new screen location to a subfolder of where the current sus screens reside, /opt/rtcds/userapps/trunk/sus/c1/medm/templates

- Rename the overview screen (SUS_CUST_HSSS_OVERVIEW.adl) to use the SUS_SINGLE nomenclature, i.e. SUS_SINGLE_OVERVIEW.adl

- Keep an eye of the cpu usage of c1pem as we add BLRMS block for other optics. 

 

 

  16504   Tue Dec 14 11:33:29 2021 TegaUpdatePEMgit repo for temp sensor and sus medm

[Temperature sensor]

Added new temp EPICs channels to database file (/cvs/cds/caltech/target/c1pem1/tempsensor/C1PEMaux.db)

Added new temp EPICs channels to slow channels ini file (/opt/rtcds/caltech/c1/chans/daq/C0EDCU.ini)

 

[SUS medm screen]

Moved new SUS screen to location : /opt/rtcds/userapps/trunk/sus/c1/medm/templates/NEW_SUS_SCREENS

Place button on the new screen to link to the old screen and replace old screens link on sitemap.

Fixed Load Coefficient button location issue

Fixed LOCKIN flow diagram issue

Fixed watchdog labelling issue

Linked STATE WORD block to FrontEnd STATUS screen

Replaced the 2x1 pit/yaw filter screens for LOCK and DAMP fliters with 3x1 LPY filter screen

*Need some more time to figure out the OPTLEV red indicator

  16750   Fri Apr 1 14:26:19 2022 Ian MacMillanSummaryPEMParticle counter setup near BS Chamber

I mounted the particle counter over the BS chamber attached to the cable tray as seen in Attachment 1. The signal cable runs through an active 30ft cable to the 1x2 rack. the wire is labeled and runs properly through the cable tray. The particle counter is plugged in at the power strip attached near the cable tray. The power cord is also labeled. 

I restarted the particle counter service in the c1psl computer in the /etc/systemd/system/ folder using the commands

sudo systemctl restart particleCounter
sudo systemctl status particleCounter

I cannged the usb hub assigned in the service file to ttyUSB0 which is what we saw the computer had named it.

Checking the channels from this elog show the same particle count as when testing with the buttons and checking the screen. It seems that the channels had been down but are now restarted.

Attachment 1: IMG_1407.jpg
IMG_1407.jpg
  16754   Sat Apr 2 15:46:13 2022 ranaSummaryPEMParticle counter setup near BS Chamber

nice - please update the particle counter page in the 40m wiki. Its probably years out of date.

Quote:

I mounted the particle counter over the BS chamber attached to the cable tray as seen in Attachment 1. The signal cable runs through an active 30ft cable to the 1x2 rack. the wire is labeled and runs properly through the cable tray. The particle counter is plugged in at the power strip attached near the cable tray. The power cord is also labeled. 

 

  16967   Thu Jun 30 19:24:24 2022 ranaSummaryPEMeffect of nearby CES construction

For the proposed construction in the NW corner of the CES building (near the 40m BS chamber), they did a simulated construction activity on Wednesday from 12-1.

In the attached image, you can see the effect as seen in our seismometers:

this image is calculated by the 40m summary pages codes that Tega has been shepherding back to life, luckily just in time for this test.

Since our local time PDT = UTC - 7 hours, 1900 UTC = noon local. So most of the disturbance happens from 1130-1200, presumably while they are setting up the heavy equipment. If you look in the summary pages for that day, you can also see the IM lost lock. Unclear if this was due to their work or if it was coincidence. Thoughts?

  12   Wed Oct 24 08:58:09 2007 steveOtherPSLlaser headtemp is up
C1:PSL-126MOPA_HTEMP is 19.3C

Half of the chiller's air intake was covered by loose paper
Attachment 1: htempup.jpg
htempup.jpg
  15   Thu Oct 25 22:02:58 2007 robRoutinePSLHEPAs maxed
In light of the SoCal fires, I turned the PSL HEPAs up to 100%.
  81   Wed Nov 7 16:07:03 2007 steveUpdatePSLPSL & IOO trend
1.5 days of happy psl-ioo with litle bumps in C1:PSL-126MOPA_HTEMP
Attachment 1: psl1.5dtrend.jpg
psl1.5dtrend.jpg
  84   Thu Nov 8 15:57:53 2007 tobinConfigurationPSLshelf removed
I removed the sheet metal shelf from the PSL enclosure, for easier access to the ISS.

ISS investigations ongoing.
  85   Thu Nov 8 18:44:01 2007 tobinConfigurationPSLISS
Tobin, Rob

With the Sense PD blocked, I adjusted the offset trim of the fourth stage in the ISS servo until the current shunt signal was zeroed. After this adjustment, we are able to crank the ISS gain all the way up to 30 dB without CS saturations (provided the HEPA is turned down to a very quiet level), getting about 35kHZ UGF at that gain setting. However, the current shunt mean value was still enormous.

Examining the current shunt signal on a fast scope, we saw an enormous (>2Vpp) 3.6 MHz sawtooth signal. Going up the chain of op-amps, we found that U1, as measured at the "Filter Out" testpoint, is oscillating wildly at 12 MHz (680 mVpp).
  88   Fri Nov 9 09:37:55 2007 steveUpdatePSLhead temp hiccup
Just an other PSL-126MOPA_HTEMP hiccup.
The water chiller is at 20.00C
Attachment 1: headtempup.jpg
headtempup.jpg
  89   Fri Nov 9 17:33:33 2007 robConfigurationPSLISS

The 3.7 MHz is actually on the light. It's the beat between the 29.5 MHz sidebands and the 33.2 MHz sidebands. There are pads in the ISS PCB for a filter to notch this frequency--John is working on it.

I also found a 1.2 ND filter on the lens which focuses the beam on the ISS diodes. I replaced it with a 0.6 ND filter, which brought the ISS DC level (on the screen) up to ~4.2 (it saturates at 5). Once John finishes the filter we should be able to crank up the gain.
  90   Fri Nov 9 21:36:14 2007 robConfigurationPSLFSS
rob, rana

We looked at the FSS a bit today. The most we could get out of it with the gain sliders was a UGF of around 95kHz. After a bit of tweaking the waveplate after the AOM, this got up to ~115kHz. We should be able to get at least 500kHz. This system needs a fair amount of work.
  95   Mon Nov 12 15:05:49 2007 robConfigurationPSLFSS

Spent a bit of time fiddling with the FSS again today. In a not-particularly-systematic manner, I raised the input-side of the 21.5MHz PC, adjusted the half-wave plate in front of it, touched up the RC alignment and the alignment onto the transmitted and reflected diodes. This got us a ~15% increase in
transmitted light, and I was able to push the UGF to 140kHz with the common gain slider at 30dB and the FAST gain slider at 22dB. The next options include adjusting the AOM setup, mode matching into the RC, and just increasing the pickoff fraction right from the getgo.
  96   Mon Nov 12 15:18:34 2007 robUpdatePSLISS

After John soldered a 3.7 MHz notch filter onto the ISS board, I took a quick TF and RIN measurement. The out-of-loop RIN is attached, including a dark noise trace, and with the gain slider at 10dB. The UGF is 35kHz with a phase margin of 30deg. John is currently doing a more thorough inspection, and will detail his findings in a subentry.
Attachment 1: ISS.png
ISS.png
  97   Mon Nov 12 23:44:19 2007 JohnUpdatePSLISS

Quote:

After John soldered a 3.7 MHz notch filter onto the ISS board, I took a quick TF and RIN measurement. The out-of-loop RIN is attached, including a dark noise trace, and with the gain slider at 10dB. The UGF is 35kHz with a phase margin of 30deg. John is currently doing a more thorough inspection, and will detail his findings in a subentry.


No progress on the ISS tonight. I tried to implement a new filter (attached)to try and gain some phase before the notch. If anything this made things worse. More work is needed.

The ISS loop is off and the power is off at the chassis.
Attachment 1: ISSfilter.jpg
ISSfilter.jpg
  98   Tue Nov 13 14:33:40 2007 JohnUpdatePSLISS filter
The transfer function from 'In Loop Error Point Monitor' to TP3 the filter out test point on the ISS board.

-33dB at 3.715MHz.
Attachment 1: PB130035.JPG
PB130035.JPG
Attachment 2: DSC_0165.JPG
DSC_0165.JPG
  101   Wed Nov 14 12:47:19 2007 tobinUpdatePSLISS
John, Tobin

With John's notch filter installed and the increased light on the ISS sensing diode, we were able to get a UGF of about 60 kHz with the gain slider set to about 20 dB. This morning we met with Stefan to learn his ISS-fu.

His recommendations for the ISS include:
  • Replace the cables from the board to the front panel connectors if this hasn't already been done.
  • Replace the input opamps with 4131's. Be sure to test both positive and negative input signals.
  • Check that all the compensation capacitors are in place and are 68 pF
  • Make sure all the feedback loops have high frequency rolloff
  • The ISS board reads the PDs differentially; make sure the PD sends differentially.
  • Add a big (ie 10uF tantalum) capacitor to the PD to suppress power supply noise
  • Add bigger power supply bypass caps to the ISS
I just took sensing noise spectra (from the PD DC bnc ports) and then took the photodiodes off the table to check that they have the negative end of the differential line connected to ground. (I placed black metal beam blocks on the table in place of the ISS PD's. Also, from the ISS schematic, it looks like it sends a differential output to the PD DC bnc ports, but we have been plugging them directly into the SR785 (grounding the shield). We should make a little BNC-doodle that separates the signal+shield to go into the A and B inputs on the spectrum analyzer.) Opening up one of the photodiodes, it appears that the negative line of the differential output is not connected. Will continue later this afternoon.
  103   Wed Nov 14 17:50:00 2007 tobinUpdatePSLISS
Here's the current wiring between the ISS and its PDs:

pin cable PD ISS
1 blue +5 +5
2 red +15 +15
3 white -15 -15
4 brown OUT IN PD +
5,6,7,8 no connection no connection GND
9 black GND IN PD -


The schematics for the ISS and the PDs are linked from our wiki.

We'll connect the ISS GND to the PD GND.
  104   Thu Nov 15 04:18:11 2007 JohnSummaryPSLPMC cavity pole measurements
In connection with our work on the ISS I attempted to measure the PMC cavity pole.

I swept the PMC PZT and looked at the transmission through the cavity on the ISS Monitor diode (which is now back on the table, feel free to remove it again tomorrow).

To avoid thermal effects I reduced the laser power using the half wave plate at the laser ouput (rotated from 6 deg to 340deg).

I swept the PZT using the triangle wave command "trianglewave C1: PSL-PMC_RAMP -3.5 3.3 20 200". I noticed that the functional form of the resonances deteriorated over the duration of the excitation. Each sweep was able to capture just over one FSR. The resonances were a little close to the 'points' of the triangle wave for my liking although I don't think PZT hysteresis was a big factor.

Looking at the data the peaks are not of uniform width across a sweep or between consecutive sweeps. Hence any results from this mesurement are not particularly useful. I can't be sure if this was due to misalignments, thermal effects, higher order mode content or some other affect.

Rob suggests sweeping the laser frequency using the NPRO PZT instead.
Attachment 1: Peaks.jpg
Peaks.jpg
  116   Tue Nov 20 10:11:33 2007 JohnSummaryPSLPMC pole measurements
We measured the PMC pole in the following way.

1. Reduced laser power by rotating lambda/2 plate at laser output. Thermal effects in the PZT distort resonance peaks. Reducing power too much leads to problems with digitisation error.

2. Sweep NPRO PZT (C1: PSL-FSS_INOFFSET) using trianglewave. Record ramp, PMC transmission and reference cavity transmission ('C1: PSL-FSS_FAST','C1: PSL-ISS_INMONPD_F','C1: PSL-FSS_RCTRANSPD_F).

3. Since the PZT cannot sweep a full FSR in the PMC we looked at the sideband resonances within the reference cavity to calibrate the actuator.
Result: 7.35 +/- 0.22 MHz/V

4. Use #3 to calibrate the x axis of the PMC transmission.

5. Fit PMC resoances to an Airy function to get finesse. Take an average, weighted according to the resnorm. Calculate cavity pole frequency.
Result: 380kHz +/- 59kHz. This corresponds to a finesse of ~936. According to this plot the nominal pole is at 488kHz and the finesse is 732.

This is by no means a definitive measurement due to the misshapen resonance peaks recorded.
Attachment 1: FittedPMCPeak.jpg
FittedPMCPeak.jpg
  121   Wed Nov 21 14:31:41 2007 robUpdatePSLFSS twiddle

I `tweaked' the FSS path today. Here's what I did:

1) Shut down the FSS autolocker

2) Turn off FSS servo

3) Assume the beam coming back from the AOM is double-first-order, and don't make any changes large enough to lose it.

4) Tweak the alignment of these components to maximize the incident power on the RC reflected diode:

a) PBS before AOM
b) AOM
c) curved mirror after the AOM

5) Translate the AOM such that the beam moves away from the PZT, then when it levels off (no more power gains with movement),
move it back just a little bit so there's a teensy drop in power. This should but the beam as close to the edge as possible,
but whether or not it's the best place is still to be determined.

6) Lock the FSS, and align the mirrors into the frequency reference cavity.

After all this, the RC transmitted power went from .57 to .73 -- probably not a big enough change to account for the missing loop
gain, but we'll know more once the loop gets measured (after Alberto stops hogging the Agilent network analyzer).

Other possible routes include a systematic check of the upstream path (e.g., the Pockels cell) and just increasing the pickoff fraction for the FSS.
  124   Tue Nov 27 15:45:08 2007 robConfigurationPSLFSS loop

It's unclear (to me, at least) what was the end result of the FSS path tweaking before Thanksgiving. Today I measured the open loop gain, and it was still around 100kHz, even with the gain sliders maxed out, but it looked really crappy with a sharp cutoff around the UGF. Then, on a lark, I pushed around the "Input Offset Adjust" slider, which sums an offset into the signal coming out of the mixer. By moving this slider to 7V, I got the UGF to 500kHz with 45 deg of phase. That would be fine, and we could go offset hunting, but the same thing happens if one puts in a large negative value! I don't really understand what's going on, but it seems like weirdness in the electronics. Unfortunately the web interface to the conlog is not running (presumably because the `new' linux1 doesn't have its apache server running) and my command line conlog efforts have been stymied. So, I don't know what the historical settings of this offset are, but zero is definitely not a good setting right now. Here's a snapshot:

FSS
UGF: 500kHz
CG : 24dB
FG : 19dB
input offset: 7V
Phase Adjust: 1.09V
Phase Button: 0
RF Amp Adjust: 7.38V

margins:
phase: 45 deg
gain: 8dB
Attachment 1: FSSsmall.jpg
FSSsmall.jpg
  127   Tue Nov 27 20:47:00 2007 tobinUpdatePSLFSS
Rana, Tobin

We looked at the RF PD signal to the FSS (siphoning off a signal via a minicircuits directional coupler) and also took an open loop transfer function of the FSS. In the transfer function we saw the step at 100 kHz (mentioned by Rob) as well as some peculiar behavior at high frequency. The high frequency behavior (with a coupling of ~ -20 dB) turns out to be bogus, as it is still present even with the beam blocked. Rearranging the cabling had no effect; the cause is apparently inside the FSS. The step at 100 kHz turns out to be a saturation effect, as it moved as we lowered the signal amplitude, disappearing as we approached -60 dBm. (Above the step, the measurement data is valid; below, bogus.)

Transfer functions will be attached to this entry.

Some things to check tomorrow: the RF signal to the PC, RF AM generation by the PC, LO drive level into the FSS, RF reflection from the PC, efficiency of FSS optical path, quality of RF cabling.
Attachment 1: fss-tf0001.pdf
fss-tf0001.pdf fss-tf0001.pdf
  128   Wed Nov 28 04:21:46 2007 ranaUpdatePSLFSS

Quote:
Rana, Tobin

We looked at the RF PD signal to the FSS (siphoning off a signal via a minicircuits directional coupler) and also took an open loop transfer function of the FSS. In the transfer function we saw the step at 100 kHz (mentioned by Rob) as well as some peculiar behavior at high frequency. The high frequency behavior (with a coupling of ~ -20 dB) turns out to be bogus, as it is still present even with the beam blocked. Rearranging the cabling had no effect; the cause is apparently inside the FSS. The step at 100 kHz turns out to be a saturation effect, as it moved as we lowered the signal amplitude, disappearing as we approached -60 dBm. (Above the step, the measurement data is valid; below, bogus.)

Transfer functions will be attached to this entry.

Some things to check tomorrow: the RF signal to the PC, RF AM generation by the PC, LO drive level into the FSS, RF reflection from the PC, efficiency of FSS optical path, quality of RF cabling.


I would also add to Tobin's entry that we believe what Rob was seeing was saturation.

With the bi-directional coupler in there, the RF signal into the FSS board clearly went UP if moved the offset slider away from zero.
With a scope looking at the IN2 testpoint, we can see that there's less than 2 mV offset at zero slider offset.

One tangential thing we noticed with the coupler is that, in lock, the amount of reflected RF is around the same as that going in to the mixer.
I have always wanted to look at this but have only had uni-directional couplers in the past. I think that the double balanced mixer is inherently
not a 50 Ohm device during the times where the diodes are being switched. IF that's the case we might do better in the future by having an RF
buffer on board just before the mixer to isolate the PD head from these reflections.
  134   Wed Nov 28 17:41:34 2007 robUpdatePSLFSS again
I investigated the FSS a bit more today. I looked at the signals coming out of the FSS frequency reference, and saw that both the LO and PC drive were distorted, non-symmetric waveforms. In addition, the LO path had a 3dB attenuator, meaning the mixer was starved. I placed mini-circuits SLP-30 filters in both paths, and now both are nice sine waves. I also took out the 3dB att. With this work, and the CG slider maxed out at 30, the FSS open loop gain (for real this time) goes up to ~250kHz. Still needs more investigation.
  136   Wed Nov 28 19:44:18 2007 tobinUpdatePSLHEPA
I found the HEPA turned off completely. I turned it on.
  137   Wed Nov 28 21:51:52 2007 tobinConfigurationPSLISS
I replaced the front-end differential receivers for the ISS's "inner-loop" sensor and monitor diode inputs with lower-noise THS4131's (formerly THS4151's). I verified operation by taking the transfer function from the "PD+" and "PD-" inputs (separately) to the testpoint following the differential receiver; the surgery appears successful.

I measured the dark spectra at the ISS's DC PD BNC ports and found a noise floor of ~ 16 nV/rtHz, compared with a floor of ~ 22 nV/rtHz last week. This seems to add up, assuming the DC PD port has 0dB gain: the 4131 has a rated noise of 1.3 nV/rtHz and the 4151 a noise floor of 7.6 nV/rtHz, a difference of 6 nV/rtHz. The other change made in that time was to add a larger power supply bypass capacitor in the PD.

There are two of the old 4151 chips still on the ISS board on the two "outer-loop" channels that we don't use. If I dig up any more 5131's I will replace these too for completeness.

There is currently no light on the ISS diodes; I'm not sure where it's intended to come from.
  141   Thu Nov 29 15:17:53 2007 robConfigurationPSLISS

I put some ISS beam on the diode on the PSL table. In the previous layout, this was the monitor diode (and it's labeled monitor) but I plugged it into the sensor jack anyways so we can run with the loop closed for now; we can just switch the cables later. The reason the beam was unclear is because someone popped up a flipper mirror which redirects the beam from the ISS into an OSA.

With the ISS gain slider at 15 dB the UGF is around 40kHz.

Why do we have such short cables for the ISS diodes?
  162   Mon Dec 3 22:20:09 2007 tobinConfigurationPSLISS
I replaced the painfully short 1' cables on the ISS photodiodes with luxurious five foot cables, made by chopping a ten foot Amphenol cable (P/N:CS-DSPMDB09MM-010) in half and using each half for one of the diodes. All of the ISS GND connections are wired to the PD GND, as is the PD- differential signal. The diodes are installed on the PSL table, but I have not tested them beyond looking at the DC values as I blocked/unblocked the beam.
  163   Tue Dec 4 23:16:35 2007 tobinUpdatePSLISS
I was confused to find that I could increase the ISS gain slider all the way from 15dB to 30dB without seeing much of any increase in gain in the measured open-loop transfer function. While making these swept-sine measurements, the saturation indicator almost never tripped, indicating it was seemingly happy. But then I noticed an odd thing: if I disable the test ("analog excitation") input, the saturation indicator trips immediately. I hooked up a scope to the current shunt test point (TP12). With the test input enabled, the loop closed, and the analog excitation port connected to the SR785, I see a a 5 Vpkpk, 2.55 MHz triangle wave there. It is there even if I set the SR785 excitation amplitude to zero, but it disappears if I disconnect the cable from the SR785.

I found oscillations at TP20, TP30, TP36, TP41, and TP42. Many of these are in the (unused) "outer loop" circuitry and currently lack compensation capacitors.
  167   Wed Dec 5 17:49:57 2007 tobinUpdatePSLISS
Attached is a plot of the ISS RIN with a variety of gain settings.

Unfortunately the dark noise is huge now--a result of the new cables & wiring?
Attachment 1: rin.pdf
rin.pdf
  169   Wed Dec 5 18:22:03 2007 tobinUpdatePSLISS dark noise
Attached is a plot of the dark noise spectrum of the ISS photodiodes (1) before fooling with them, (2) after replacing the 4151's with 4131's (improvement!), and (3) after replacing the cables and changing the wiring (disaster!).
Attachment 1: sense_noise.pdf
sense_noise.pdf
  171   Wed Dec 5 20:32:51 2007 tobinUpdatePSLISS dark noise
The ISS dark noise is not coming from the PD heads; the spectrum is essentially unchanged when the PD is unplugged from the ISS. Did the input opamps both get semi-fried in the same way? (They worked so well when they were first installed.) What else changed? I'm baffled. Frown
  177   Thu Dec 6 19:30:43 2007 tobinUpdatePSLISS dark noise - 60 Hz!
A higher resolution spectrum [attached] shows that nearly all of the excess dark noise on the ISS is in 60 Hz harmonics (with some 256 Hz harmonics too--are these from the DAQ?).

With the loop closed and the slider at 5dB, the laser light coming out has a noise floor of 10^-7 RIN or better from 40 Hz to 8 kHz.

Now to figure out why all this 60 Hz is getting in... (I tried turning off all the lights and the HEPA, and moving the SR785 further away, none of which did anything.)
Attachment 1: iss.pdf
iss.pdf
ELOG V3.1.3-