40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 245 of 327  Not logged in ELOG logo
ID Date Author Type Categoryup Subject
  13894   Tue May 29 16:22:43 2018 KiraUpdatePEMparts list

I've updated the parts list to be an excel document and included every single part we will need. This is ony a first draft so it will probably be updated in the future. I also made a mistake in hole sizing for the front panel so I've updated it and attached it as well (second attachment).

Edit: re-attached the EX can panel fpd file so that everything is in one place

Attachment 1: parts_list_-_Sheet1.pdf
parts_list_-_Sheet1.pdf
Attachment 2: 1U-panel-2.fpd
Attachment 3: EX-can-panel.fpd
  13895   Tue May 29 16:33:04 2018 SteveUpdatePEMair cond filters replaced

Chris replaced some air condition filters and ordered some replacement filter today.

Quote:

 

Quote:

 

Quote:

Yesterday morning was dusty. I wonder why?

The PRM sus damping was restored this morning.

Yesterday afternoon at 4 the dust count peaked 70,000 counts

Manasa's alergy was bad at the X-end yesterday. What is going on?

There was no wind and CES neighbors did not do anything.

Air cond filters checked by Chris. The 400 days plot show 3 bad peaks at 1-20, 2-5 & 2-19

 

  13899   Wed May 30 23:57:08 2018 gautamUpdatePEMBurning smell in office area / control room

[koji, gautam]

We noticed quite a strong burning smell in the office area and control room ~20mins ago. We did a round of the bake lab, 40m VEA and the perimeter of the CES building, and saw nothing burning. But the smell persists inside the office area/control room (although it may be getting less noticeable). There is a whining noise coming from the fan belt on top of the office area. Anyways, since nothing seems to be burning down, we are not investigating further.

Steve [ 10am 5-31 ] we should always check partical count in IFO room

Service requested 

 

  13903   Thu May 31 15:48:16 2018 KiraUpdatePEMrunning PID script with seismometer

I have attached the result of running the PID script on the seismometer with the can on. The daily fluctuations are no more than 0.07 degrees off from the setpoint of 39 degrees. Not really sure what happened in the past day to cause the strange behavior. It seems to have returned back to normal today.

Attachment 1: can-on-pid.png
can-on-pid.png
  13922   Wed Jun 6 15:12:29 2018 KiraUpdatePEMparts from lab

Got this 1U box from the Y arm that we could potentially use (attachment 1). It doesn't have handles on the front but I guess we could attach them if necessary. Attachment 2 is a switch that could be used instead of a light up switch, but now we need to add LEDs on the front panel that indicate that the switch is functional. Attachment 3 is a terminal block that we can use to attach the 16 gage wire to since it is thick and attaching it directly to the board would be difficult. If this is alright to use then I'll change up my designs for the front panel and PCB to accomodate these parts.

Attachment 1: IMG_20180606_141149.jpg
IMG_20180606_141149.jpg
Attachment 2: IMG_20180606_141851.jpg
IMG_20180606_141851.jpg
Attachment 3: IMG_20180606_141912.jpg
IMG_20180606_141912.jpg
  13964   Thu Jun 14 15:24:32 2018 SteveUpdatePEM ADC DAC In Line Test Boards are in

We have 6 of these boards now in cabinet E7

Quote:

I wired all 32 channels going to the AA board directly to the ADC as described in the previous log. However, instead of using the old AA board and bypassing the whole circuit, I just used a breakout board as is shown in the first attachment. I put the board back in the rack and reconnected all of the cables.

The seismic BLRMs appear to be working again. A PSD of the BS seismometers is shown in attachment 2. Tomorrow I'll look at how much the ADC alone is suppressing the common mode 60 Hz noise on each of the channels.

Steve: 5 of ADC DAC In Line Test Boards [ D060124 ] ordered. They should be here within 10 days.

 

Attachment 1: ADC_DAC_in_(1).JPG
ADC_DAC_in_(1).JPG
  13979   Mon Jun 18 11:12:23 2018 KiraSummaryPEMfinishing up work at the lab

Since I am finishing my job at the lab, I have stored all my electronics in a box (attachment 1) and placed it under the table in the control room where some other electronics are stored. The box contains the heater circuit box, two temperature sensor boards, one temperature sensor, a short power cable and +/- 15V supply cables. In the lab I left the wires for the current setup and tied them down to the wall so that they aren't in the way (attachment 2). I left the can as is and the other temperature sensor is still attached to the inside of the can. I have labeled the wires going from the sensor as 'in' and 'out'. I've also left the wires for the heater there as well (attachment 3). I turned off the PID control and deactivated the tmux session on megatron.

Thanks to Rana and the LIGO team for giving me the opportunity to work at the 40m on this project with the seismometer.

Attachment 1: IMG_20180618_101640.jpg
IMG_20180618_101640.jpg
Attachment 2: IMG_20180618_093920.jpg
IMG_20180618_093920.jpg
Attachment 3: IMG_20180618_093932.jpg
IMG_20180618_093932.jpg
  13990   Wed Jun 20 09:16:56 2018 SteveUpdatePEMdusty lab

You should wipe off the table cover before you take it off next time.

It is important to turn up the PSL encloure HEPA Variac voltage if you are working in there. It takes less than 10 minutes to reach lab condition.

Lab air count normal. It is not logged. I have a notebook of particle count on the SP table next to the Met One counter.

Quote:

Chris replaced some air condition filters and ordered some replacement filter today.

 

 

Attachment 1: AP.JPG
AP.JPG
Attachment 2: ITMY.JPG
ITMY.JPG
Attachment 3: ITMX.JPG
ITMX.JPG
Attachment 4: SP.JPG
SP.JPG
  14001   Thu Jun 21 23:59:12 2018 shrutiUpdatePEMSeismometer temp control

We (Rana and I) are re-assembling the temperature controls on the seismometer to attempt PID control and then improve it using reinforcement learning.

We tried to re-assemble the connections for the heater and in-loop temperature sensor on the can that covers the seismometer.

We fixed (soldered) two of the connections from the heater circuit to the heater, but did not manage to get the PID working as one of the wires attached to the MOSFET had come off. Re-soldering the wire would be attempted tomorrow.

Equipment for undertaking all this is still left at the X-end of the interferometer and will be cleared soon.

  14016   Mon Jun 25 22:27:57 2018 shrutiUpdatePEMSeismometer temp control - heater circuit

After removing all the clamping screws from the heater circuit board, I soldered the wire connecting IRF630 to the output of OP27, which had come off earlier. This can only be a temporary fix as the wire was not long enough to be able to make a proper solder joint. I also tried fixing two other connections which were also almost breaking.

After re-assembling everything I found out that one of the LEDs was not working. The most likely cause seems to be an issue with LM791, LM 781 or the LED itself. Due to the positioning of the wires, I was unable to test them today but will try again possibly tomorrow.

Equipment used for this is still lying at the X end.

Quote:

We (Rana and I) are re-assembling the temperature controls on the seismometer to attempt PID control and then improve it using reinforcement learning.

We tried to re-assemble the connections for the heater and in-loop temperature sensor on the can that covers the seismometer.

We fixed (soldered) two of the connections from the heater circuit to the heater, but did not manage to get the PID working as one of the wires attached to the MOSFET had come off. Re-soldering the wire would be attempted tomorrow.

Equipment for undertaking all this is still left at the X-end of the interferometer and will be cleared soon.

  14030   Thu Jun 28 11:05:48 2018 shrutiUpdatePEMSeismometer temp control equipment

Earlier today I cleared up most of the equipment at the X end near the seismometer to make the area walkable. 

In the process, I removed the connections to the temperature sensor and placed the wires on top of the can.

  14113   Sun Jul 29 20:03:02 2018 ranaUpdatePEMSeismometer temp control

While Shruti is re-building Kira's heater circuit, I looked up how to do one of these (i.e. what does a real EE say about how to build a current source?):

It turns out that there is an Analog Devices application note (AN-968) about this (as there usually is once we get tired of playing around and try to look up the right answer).

I've linked to the note and attached the recommended schematic for high current applications. We'll go ahead as is, but we'll make a PCB according to this App Note for the v3 circuit.

 

Attachment 1: Screen_Shot_2018-07-29_at_8.00.27_PM.png
Screen_Shot_2018-07-29_at_8.00.27_PM.png
  14185   Mon Aug 27 09:14:45 2018 SteveUpdatePEMsmall earth quakes

Small earth quakes and suspensions. Which one is the most free and most sensitive: ITMX

 

Attachment 1: small_EQs_vs_SUSs.png
small_EQs_vs_SUSs.png
  14186   Tue Aug 28 15:29:19 2018 SteveFrogsPEMRat is cut

The rat is cut by mechanical trap and it was removed from ITMX south west location.

A nagy kover patkanyt a fogo elkapta es megolte.

Attachment 1: rat#2.png.png
rat#2.png.png
  14266   Fri Nov 2 10:24:20 2018 SteveUpdatePEMroof cleaning

Physical plan is cleaning our roof and gutters today.

  14321   Tue Nov 27 10:50:20 2018 SteveUpdatePEMearth quake Mexico

Nothing tripped.

 

Attachment 1: 5.5M.Mexico.png
5.5M.Mexico.png
  14323   Thu Nov 29 08:13:33 2018 SteveUpdatePEMEQ 3.9m So CA

EQ did not trip anything. atm1

Just a REMINDER: our vacuum system is at atm to help the vacuum upgrade to Acromag.

Exceptions: cryo pump and 4 ion pumps

It is our first rainy day of the season..The roof is not leaking.

 Vac Status: The vac rack power was recycled yesterday and power to controller TP1,2 and 3 restored. atm3

                     VME is OFF.        Power to all other instrument are ON.       23.9Vdc 0.2A

ETMY sus tower with locked optic in HEPA tent at east end is standing by for action.

 

Attachment 1: 3.9mSoCA.png
3.9mSoCA.png
Attachment 2: Vac_as_today.png
Vac_as_today.png
Attachment 3: as_is.png
as_is.png
  14949   Tue Oct 8 08:08:18 2019 gautamUpdatePEMPEM BLRMS anomaly

Yesterday, Koji and I noticed (from the wall StripTool traces) that the vertex seismometer RMS between 0.1-0.3 Hz in the X-direction increased abruptly around 6pm PDT. This morning, when I came in, I noticed that the level had settled back to the normal level. Trending the BLRMS channels over the last 24 hours, I  see that the 0.3-1 Hz band in the Z direction shows some anomalous behaviour almost in the exact same time-band. Hard to believe that any physical noise was so well aligned to the seismometer axes, I'm inclined to think this is indicative of some electronics issues with the Trillium interface unit, which has been known to be flaky in the past.

Attachment 1: PEManomaly.png
PEManomaly.png
  14989   Wed Oct 23 11:49:21 2019 gautamUpdatePEMPEM BLRMS anomaly

I looked into the seismometer situation a bit more today. Here is the story so far - I think more investigation is required:

  1. There is an abrupt change in the PEM BLRMS channels around 6pm PDT every day. This has been consistently seen for the last two weeks.
  2. The seismometer spectra look normal - see Attachment #1. The reference traces are from some months ago. There is elevated activity between 0.1-0.3 Hz, but this is seen in all the seismometers in all 3 DoFs.
  3. I looked at the minute trend of the raw seismometer outputs (before being BLRMSed) for the last 200 days and don't see any abrupt change in characteristics (the data gap is due to the issue in this thread).
  4. All the correct BLRMS filters seem to be engaged in the respective filter banks.

Attachment #2 has some spectrograms (they are rather large files). They suggest that the increase in noise in the 0.1-0.3 Hz band in the BS seismometer X channel is real - but there isn't a corresponding increase in the other two seismometers, so the problem could still be electronics related.

Quote:

Yesterday, Koji and I noticed (from the wall StripTool traces) that the vertex seismometer RMS between 0.1-0.3 Hz in the X-direction increased abruptly around 6pm PDT. This morning, when I came in, I noticed that the level had settled back to the normal level. Trending the BLRMS channels over the last 24 hours, I  see that the 0.3-1 Hz band in the Z direction shows some anomalous behaviour almost in the exact same time-band. Hard to believe that any physical noise was so well aligned to the seismometer axes, I'm inclined to think this is indicative of some electronics issues with the Trillium interface unit, which has been known to be flaky in the past.

Attachment 1: seisAll_20191021.pdf
seisAll_20191021.pdf
Attachment 2: specGrams.zip
  14992   Thu Oct 24 18:37:15 2019 gautamUpdatePEMT240 checkout

Summary:

The Trillium T240 seismometer needs mass re-centering. Has anyone done this before, and do we have any hardware to do this?

Details:

I went to the Trillium interface box in 1X5. In this elog, Koji says it is D1000749-v2. But looking at the connector footprint on the back panel, it is more consistent with the v1 layout. Anyway I didn't open it to check. Main point is that none of the backplane data I/O ports are used. We are digitizing (using the fast CDS system) the front panel BNC outputs for the three axes. So of the various connectors available on the interface box, we are only using the front panel DB25, the front panel BNCs, and the rear panel power.

The cable connecting this interface box to the actual seismometer is a custom one I believe. It has a 19 pin military circular type hermetic connector on one end, and a DB25 on the other. Power is supplied to the seismometer from the interface box via this cable, so in order to run the test, I had to use a DB25 breakout board to act as a feedthrough and peek at the signals while the seismometer and interface boards were connected. I used Jenne's mapping of the DB25--> 19 pin connector (which also seems consistent with the schematic). Findings:

  1. We are supplying the Trillium with 39 V DC between the +PWR and -PWR pins, while the datasheet specifies 9V to 36V DC isolated. Probably this is okay?
  2. The analog (AGND) and digital (DGND) ground pins are shorted. Is this okay?
  3. I measured the DC voltages between the AGND pin and each of the mass position outputs.
    • These are supposed to indicate when the masses need re-centering.
    • The nominal output ranges for these are +/- 4 V single-ended.
    • I measured the following values (I don't know how the U,V,W basis is mapped onto the cartesian X,Y,Z coordinates):
      U_MP: 0.708 V
      V_MP: -2.151 V
      W_MP: -3.6 V
    • So at the very least, the mass needs centering in the W direction (the manual recommends doing the re-centering procedure when one of these indicators exceeds 3.5 V in absolute value).
  4. I also checked the DC voltages of the (X,Y,Z) outputs of the seismometer on the front panel BNCs, and also on the DB25 connector (so directly from the seismometer). These are rated to have a range of 40 Vpp differential between the pins. I measured ~0V on all the three axes - this is a bit confusing as I assumed a de-centered mass would lead to saturation in one of these outouts, but maybe we are measuring velocities and not positions?
  5. We probably should consider monitoring these signals long term to inform of such drifts, what is the spare channel situation in the c1sus acromag?
  6. Interestingly, today evening, there is no excess noise in the 0.1-0.3 Hz band in the X-axis of the seismometer even though it is past 6pm PDT now, which is usually the time when the excess begins to show up. The z-axis 0.3-1Hz BLRMS channel has flatlined though...

I am holding off on attempting any re-centering, for more experienced people to comment.

  15013   Tue Nov 5 12:37:50 2019 gautamUpdatePEMT240 interface unit pulled out

I removed the Trillium T240 DAQ interface unit from 1X4 for investigation.

It was returned to the electronics rack and all the connections were re-made. Some details:

  1. The board is indeed a D1000749-v2 as Koji said it is. There is just an additional board (labelled D1001872 but for which there is no schematic on the DCC) inside the 1U box that breaks out the D37 connector of the v2 into 3 D15 connectors. I took photos.
  2. Armed with the new cable Chub got, and following the manual, I ran the re-centering routine.
    • Now all the mass-monitoring position voltages are <0.3 V DC, as the manual tells me they should be.
    • I noticed that when the seismometer is just plugged in and powered, it takes a few minutes for the mass monitoring voltages to acquire their steady state values.
    • The V indicator reported ~-2V DC, and the W indicator reported -3.9V DC.
    • While running the re-centering routine, I monitored the mass-position indicator voltages (via the backplane D15 connector) on an oscilloscope. See Attachment #1 for the time series. The data was rather noisy, I don't know why this is, so I plot the raw data in light colors and a filtered version in darker colors. Also, there seems to be a gain of x2 in the voltages on the backplane relative to what the T240 manual tells me I should expect, and the values reported when I query the unit via the serial port.
    • We should ideally just install another Acromag ADC in the c1susaux box and acquire these and other available diagnostic information, since the signals are available.
    • We should also probably check the mass position indicator values in a few days to see if they've drifted off again.
    • Looking at the raw time series / spectra of the BS channels, I see no obvious signatures of any change. 
    • I will run a test by locking the PRC and looking for coherence between the seismometer data and angular motion witnessed by the POP QPD, as this was what signalled my investigation in the first place.

Update 445pm: Seems to have done something good - the old feedforward filters reduce the YAW RMS motion by a factor of a few. Pitch performance is not so good, maybe the filter needs re-training, but I see coherence, see Attachment #2 for the frequency domain WF.

Attachment 1: T240_recenter.pdf
T240_recenter.pdf
Attachment 2: ffPotential.pdf
ffPotential.pdf
  15022   Wed Nov 13 19:34:45 2019 gautamUpdatePEMFollow-up on seismometer discussion

Attachment #1 shows the spectra of our three available seismometers over a period of ~10ksec.

  • I don't understand why the z-axis motion reported by the T240 is ~10x lower at 10 mHz compared to the X and Y motions. Is this some electronics noise artefact?
  • The difference in the low frequency (<100mHz) shapes of the T240 compared to the Guralps is presumably due to the difference in the internal preamps / readout boxes (?). I haven't checked yet.
  • There is almost certainly some issue with the EX Guralp. IIRC this is the one that had cabling issues in the past, and also is the one that was being futzed around for Tctrl, but also could be that its masses need re-centering, since it is EX_X that is showing the anomalous behaviour.
  • The coherence structure between the other pairs of sensors is consistent.

Attachment #2 shows the result of applying frequency domain Wiener filter subtraction to the POP QPD (target) with the vertex seismometer signals as witness channels.

  • The dataset was PRMI locked with the carrier resonant, ETMs misaligned.
  • The dashed lines in these plots correspond to the RMS for the solid line with the same color.
  • For both PIT and YAW, I am using BS_X and BS_Y seismometer channels for the MISO filter inputs.
  • In particular for PIT, I notice that I am unable to get the same level of performance as in the past, particularly around ~2-3 Hz.
  • The BS seismometer health indicators don't signal any obvious problems with the seismometer itself - so something has changed w.r.t. how the ground motion propagates to the PR2/PR3? Or has the seismometer sensing truly degraded? I don't think the dataset I collected was particularly bad compared to the past, and I confirmed similar performance with a separate PRMI lock from a different time period.
Attachment 1: seisAll_20191111.pdf
seisAll_20191111.pdf
Attachment 2: ffPotential.pdf
ffPotential.pdf
  15023   Wed Nov 13 20:15:56 2019 ranaUpdatePEMFollow-up on seismometer discussion

this is due to the Equivalence Principle: local accelerations are indistinguishable from spacetime curvature. On a spherical Earth, the local gradient of the metric points in the direction towards the center of the Earth, which is colloquially known as "down".

Quote:

I don't understand why the z-axis motion reported by the T240 is ~10x lower at 10 mHz compared to the X and Y motions. Is this some electronics noise artefact?

 

  15024   Wed Nov 13 23:40:15 2019 gautamUpdatePEMFollow-up on seismometer discussion

Here is some disturbance in the spacetime curvature, where the local gradient of the metric seems to have been modulated (in the "downward" as well as in the other two orthogonal Cartesian directions) at ~1 Hz - seems real as far as I can tell, all the suspensions were being shaken about and all the seismometers witnessed it, though the peak is pretty narrow. A broader, less prominent peak also shows up around 0.5 Hz. We couldn't identify any clear source (no LN2 fill-up / obvious CES activity). This event lasted for ~45 mins, and stopped around 2315 local time. Shortly (~5min) after the ~1 Hz peak died down, however, the 3-10 Hz BLRMS channel reports an increase by ~factor of 2. 

Onto trying some locking now that the suspensions have settled down somewhat.

Quote:

this is due to the Equivalence Principle: local accelerations are indistinguishable from spacetime curvature. On a spherical Earth, the local gradient of the metric points in the direction towards the center of the Earth, which is colloquially known as "down".

Attachment 1: seisAll_20191111_1Hz.pdf
seisAll_20191111_1Hz.pdf
  15025   Thu Nov 14 12:11:04 2019 ranaUpdatePEMFollow-up on seismometer discussion

at 1 Hz' this effect is not large so that's real translation. at lower frequencies a ground tilt couples to the horizontal sensors at first order and so the apparent signal is amplified by the double integral. drawing a free body diagram u can c that

x_apparent = (g / s^2) * theta

but for vortical this not tru because it already measures the full free fall and the tilt only shows up at 2nd order

  15027   Fri Nov 15 00:18:41 2019 ranaUpdatePEMFollow-up on seismometer discussion

The large ground motion at 1 Hz started up again tonight at around 23:30. I walked around the lab and nearby buildings with a flashlight and couldn't find anything whumping. The noise is very sinusoidal and seems like it must be a 1 Hz motor rather than any natural disturbance or traffic, etc. Suspect that it is a pump in the nearby CES building which is waking up and running to fill up some liquid level. Will check out in the morning.

Estimate of displacement noise based on the observed MC_F channel showing a 25 MHz peak-peak excursion for the laser:

dL = 25e6 * (13 m / (c / lambda)

      = 1 micron

So this is a lot. Probably our pendulum is amplifying the ground motion by 10x, so I suspect a ground noise of ~0.1 micron peak-peak.

(this is a native PDF export using qtgrace rather than XMgrace. uninstall xmgrace and symlink to qtgrace.)

Attachment 1: MCshake.pdf
MCshake.pdf
  15030   Fri Nov 15 12:16:48 2019 gautamUpdatePEMFollow-up on seismometer discussion

Attachment #1 is a spectrogram of the BS sesimometer signals for a ~24 hour period (from Wednesday night to Thursday night local time, zipped because its a large file). I've marked the nearly pure tones that show up for some time and then turn off. We need to get to the bottom of this and ideally stop it from happening at night because it is eating ~1 hour of lockable time.

We considered if we could look at the phasing between the vertex and end seismometers to localize the source of the disturbance.

Attachment 1: BS_ZspecGram.pdf.zip
  15032   Mon Nov 18 14:32:53 2019 gautamUpdatePEMFollow-up on seismometer discussion

The nightly seismic activity enhancement continued during the weekend. It always shows up around 10pm local time, persists for ~1 hour, and then goes away. This isn't a show stopper as long as it stops at some point, but it is annoying that it is eating up >1 hour of possible locking time. I walked over to CES, no one there admitted to anything - there is an "Earth Surface Dynamics Laboratory" there that runs some heavy equipment right next to us, but they claim they aren't running anything post ~530pm. Rick (building manager ?) also doesn't know of anything that turns on with the periodicity we see. He suggested contacting Watson but I have no idea who to talk to there who has an overview of what goes on in the building. 😢 

  15036   Tue Nov 19 21:53:57 2019 gautamUpdatePEMFollow-up on seismometer discussion

The shaking started earlier today than yesterday, at ~9pm local time.

While the IFO is shaking, I thought (as Jan Harms suggested) I'd take a look at the cross-spectra between our seismometer channels at the dominant excitation frequency, which is ~1.135 Hz. Attachment #1 shows the phase of the cross spectrum taken for 10 averages (with 30mHz resolution) during the time period when the shaking was strong yesterday (~1500 seconds with 50% overlap). The logic is that we can use the relative phasing between the seismometer channels to estimate the direction of arrival and hence, the source location. However, I already see some inconsistencies - for example, the relative phase between BS_Z and EX_Z suggests that the signal arrives at the EX seismometer first. But the phasing between EX_Y and BS_Y suggests the opposite. So maybe my thinking about the problem as 3 co-located sensors measuring plane-wave disturbances originating from the same place is too simplistic? Moreover, Koji points out that for two sensors separated by ~40m, for a ground wave velocity of 1.5 km/s, the maximum phase delay we should see between sensors is 30 msec, which corresponds to ~10 degrees of phase. I guess we have to undo the effects of the phasing in the electronics chain.

Does anyone have some code that's already attempted something similar that I can put the data through? I'd like to not get sucked into writing fresh code.

🤞 this means that the shaking is over for today and I get a few hours of locking time later today evening.

Another observarion is that even after the main 1.14 Hz peak dies out, there is elevated seismic acitivity reported by the 1-3 Hz BLRMS band. This unfortunately coincides with some stack resonance, and so the arm cavity transmission reports greater RIN even after the main peak dies out. Today, it seems that all the BLRMS return to their "nominal" nighttime levels ~10 mins after the main 1.14 Hz peak dies out.

Attachment 1: seisxSpec.pdf
seisxSpec.pdf
  15082   Fri Dec 6 17:49:46 2019 ranaSummaryPEMJump test of seismometers: EX needs recentering

Yehonathan, please center the EX seismometer.

The attached PDF shows the seismometer signals (I'm assuming that they're already calibrated into microns/s) during the lab tour for the art students on 11/1. The big spike which I've zoomed in on shows the time when we were in the control room and we all jumped up at the same time. There were approximately 15 students each with a mass of ~50-70 kg. I estimate that out landing times were all sync'd to within ~0.1 s.

Attachment 1: Seismometers.pdf
Seismometers.pdf
Attachment 2: src.tgz
  15083   Sun Dec 8 20:15:41 2019 ranaSummaryPEMJump test of seismometers: EX needs recentering

I have re-centered the EX (and EY) seismometers. They are Guralp CMG40-T, and have no special centering procedure except cycling the power a few times. I turned off the power on their interface box, then waited 10s before turning it back on.

The fist atm shows the comparison using data from 8-9 PM Saturday night:

  1. there seems to be a factor of 2 calibration diff between the T240 near the BS, and the Guralp seismometers at the end. Which one is right? surpriseWhen was the last time they were cross calibrated?
  2. The low coherence between BS_X and EX_X shows the problem. They should be very coherent (> 0.9) for 0.1-1 Hz.sad

 

Attachment 1: seis_all_191208.pdf
seis_all_191208.pdf
  15086   Mon Dec 9 13:08:24 2019 YehonathanSummaryPEMJump test of seismometers: EX needs recentering

I check the seismometers in the last 14 hours (Attached). Seems like the coherenece is restored in the x direction.

 

 

Attachment 1: seis_191208.pdf
seis_191208.pdf
  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. 

  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
ELOG V3.1.3-