[Annalisa, Jenne, Nic]

After having troubles with the Xarm earlier (maybe Manasa can write/say something about this?  Something about perhaps seeing the phase tracker jump, and cause it to lose lock?), we moved on to the Y arm. 

Annalisa locked the Yarm green, and closed the ALS loop.  I believe that earlier today, she tuned the gain such that we don't start getting gain peaking at a few hundred Hz.  We would like to get a script going, so that it's not so labor intensive to reclose the ALS loop after an MC lockloss....but that's a daytime task.

We then found the IR resonance, using only the Yarm ALS system.  After Manasa's work yesterday, the Yarm was very stable while locked with the ALS.  We took a power spectrum of POY11_I_ERR, which I have calibrated using the number in elog 6834 of 1.4e12 cts/m, or 7.14e-13 m/ct.  See the figure below.

After that, we changed the offsetter2 offset such that the arm was off resonance, but not so far off that we crossed any significant resonances (in particular, we wanted to not go as far as the 55MHz resonance). 

Then, I tried to lock the PRMI for a while, but the alignment wasn't very good.  We knew that the Yarm was well aligned, since our IR resonance was > 0.98, but it had been a while since we had aligned the X arm.  I tweaked the ITMX position to make the Michelson dark, and then tried acquiring PRMI lock.  At first, I tried with REFL165 I and Q, but with the non-ideal alignment and the offset in the 165 diode (LSC offsets was not run this evening), I wasn't catching any locks.  I then switched to AS55Q and REFL33I, but wasn't able to catch lock there either. 

The MC lost lock, which made us lose the ALS loop, but the ALS had been locked for more than 30 minutes, at least.  I tried locking the PRMI with the current alignment (after having misaligned ETMY), but was only able to get lock stretches of 1 second at maximum.

We are calling it a great success for the night, since we have confirmed that, at least for the Yarm, Manasa's beatbox work has improved things.  Also, we have a pretty solid plan for trying the PRMI+arm tomorrow, even though it didn't work out tonight.

 The X arm was locked with TRX>0.98 earlier last night while I was measuring the out of loop noise of the phase tracker.

[chub, gautam]

Summary:

Y arm was locked at low power in air.

Details:

1. ITMY chamber door was removed at ~10am with Bob's help.
2. ETMY table leveling was found to have drifted significantly (3 ticks on the spirit level, while it was more or less level yesterday, should look up the calib of the spirit level into mrad). Chub moved some weights around on the table, we will check the leveling again tomorrow.
3. IMC was locked.
4. TT2 and brass alignemnt tool was used to center beam on ETMY.
5. TT1 and brass alignment tool was used to center beam on ITMY. We had to do a c1susaux reboot to be able to move ITMY. Usual precautions were taken to avoid ITMX getting stuck.
6. ETMY was used to make return beam from the ETM overlap with the in-going beam near ITMY, using a holey IR card.
7. At this point, I was confident we would see IR flashes so I decided to do the fine alignment in the control room.

We are operating with 1/10th the input power we normally have, so we expect the IR transmission of the Y arm to max out at 1 when well aligned. However, it is hovering around 0.05 right now, and the dominant source of instability is the angular motion of ETMY due to the Oplev loop being non-functional. I am hesitant to do in-chamber work without an extra pair of eyes/hands around, so I'll defer that for tomorrow morning when Chub gets in. With the cavity axis well defined, I plan to align the green beam to this axis, and use the two to confirm that we are well clear of the Parabola.

* Paola, our vertex laptop, and indeed, most of the laptops inside the VEA, are not ideal to work on this kind of alignmment procedure, it would be good to set up some workstations on which we can easily interact with multiple MEDM screens,

 [Ayaka, Jenne]

We put the POY beam onto the POY PD.  The Yarm is currently locked on IR with ~0.65 transmission.

[Rana, EricQ, Jenne]

We locked the Yarm by using the CM board this evening. 

POY is going from its demod board to the CM board, and then the slow output of that is going to the POY channel of the whitening, and then on to the ADC.  So, with no AO path engaged, this is basically like regular Yarm locking. 

First of all, Den and Koji back in December were concerned that they were seeing some EOM saturation in the fast path, but we don't think that's an issue.  We looked at the FSS PCDRIVE while we increased the AO gain.  In fact, it looks like the offset is coming from the MC board's IN2 slider.  Even with no input on that slider, increasing its value puts an offset into the MC.  To fix this, I am going to put a 6.8uF cap in series with R30 in the MC board, which is part of the crossbar switch where the IN1 and IN2 get summed.  This should AC-couple the output of the IN2 slider before the summing node.

We aren't sure which sign to use for the AO path of the CM board...Eric is doing some modelling to see if he can figure it out.  He's going to try to see which spectra (below) his model matches.

For the spectra, we have a reference trace with no AO path, a trace with "Plus" polarity on the CM board which started to show a peak when the value of the MC IN2 slider was at about -6 dB, and a trace with "Minus" polarity, which started to show a peak when the value of the MC IN2 slider was at about -16 dB. 

We took loop measurements for each of the Plus and Minus cases. Something that seems a little weird is how shallow of a slope we have in both cases near our UGF.

Just to be clear, the normal POY signals are not currently present, so the restore POY script will not result in the arm locking. POY11_I is turned off, POY11_Q is the output of the CM board, which can be used to lock the arm, as we did tonight. 

The POY digital demos angle went -56 -> 90, to get all of POY11_Q_IN1 to POY11_I_ERR

Miscellaneous things:

• Right now, the cable from CM board ->MC board is a BNC. There appeared to be a differential 2-pin lemo hanging around for this purpose, but it didn't seem to be transmitting the signal. However, we will want something better than a BNC to keep this signal clean. 
• I took SR785 TFs of the CM board from IN to the slow and fast outs. They looked reasonable, and will be posted in time. 
• We enabled the 79:1.6k filter in the CM screen (though it is unclear if these are the actual values...), and put in its inverse in the digital path. I.e. we only want this shape in the AO path, to give it 1/f shape in the vicinity of the crossover. This is only necessary in the uncoupled cavity case. 

 (Edited this post; Forgot to account for the FMs other than 4 and 5... it now agrees better!)

I did some quick MATLAB simulation of the relevant loops to try and understand what was going on. I put the digital UGF around 200Hz, and then brought in the AO path with both signs. 

In these plots, blue is digital only, green is AO+digital with the crossover happening at the UGF, and red is the AO gain set to five times of what it was in the green curve. 

Based on the phase curves in the loop measurements, I would be inclined to say the pink -AO case corresponds to the opposite sign plot, and the +AO case to the same sign plot. 

This correspondence also holds for the appearance of the peaks in the noise curves, the Opposite sign case has a dip in loop gain at ~50Hz (pink curve, -AO), same sign around ~30Hz (brown curve, +AO). 

However, both of these look like they become unstable at some point in the transition! This agrees with our experience last night...

I'll fiddle around and try to come up with some compensating digital filter that will make the Opposite sign scenario work. 

The MATLAB code I used to make these plots is attached. 

 I think that's about halfway there. Since this needs to be a precise comparison, we cannot use so many approximations.

We've got to include the digital AA and AI filters as well as the true, measured, time delay in the system. Also the measured/fitted TF of the CM board with the 79:1.6k filter engaged. We want an overall phase accuracy between Jenne's measured TF from last night and this model (i.e. on the same plot with the residual plotted).

Is there a cavity pole in the model? Should be at ~1.6 kHz.

[Jenne, Jamie]

We recovered lock and alignment of the Y arm.  TRY_OUT is now at ~0.9, after tweaking {I,E}TMY pit/yaw and PZT2.  YARM_GAIN is 0.1.

I saved ITMY, ETMY, and PZT2 alignments in the IFO_ALIGN screen with the new alignment save/restore stuff I got working.

Working on getting Yarm ASS working now...

To facilitate Yuki's alignment of the EY green beam into the Yarm cavity, I have changed the LSC triggering and PowNorm settings to use only the reflected light from the cavity to do the locking of Arm Cavity length to PSL. Running the configure script should restore the usual TRY triggering settings. Also, the X arm optics were macroscopically misaligned in order to be able to lock in this configuration.

This work was done by Ancal and I. 

To recallibrate the op-lev for ETMY, a python script was first written to calculate the change in distance in x or y that the photodiode array will see when the mirror incurs a change in yaw or pitch. The python script approximates d by integrating, using a reimann sum, the area under a gaussian curve, given by I(r)= I_o exp(−2r²/ 2w(z)²), where r is the radial position, and w(z) is the waist (radius) size of the gaussian beam where power reaches 1/e² of its maximum. The distance d, is the difference from the center of the gaussian to the point at which the beam profile has a normalized area under the curve equal to that of the percent of the beam profile showing on one half of the circular photodiode array.

     Above, the gaussian is related to the translation of the beam profile on the photodiode where the area calculated under the curve of the gaussian, is equivalent to the ratio of the beam profile in 2 adjacent quaters of the photodiode array. 

The gaussian, is directly related to the waist size of the laser beam profile, and thus a beam profiler was used to calculate the waist size over an average of 100 takes. Due to the thickness of the beam profiler, we were unable to get a direct measurement of the size of the beam at the exact location of the photodiode. Instead, we took two seperate measurements while moving the profiler 1 inch further away from the photodiode and back calculated the average size of the beam at the photodiode assuming that at this distance away from the source, the beams width would expand linearly. This provided a 2*waist size of 1625 ± 40 um. 

     image above displays the laser beam profiler used to approximate the waist size of the op-lev laser.

The physically calculated translation of the beam profile, d, can then be used to determine the overall angle, theta, that the mirror has moved to create this offset. The relation between distance and theta is Theta = d/2R, where R is the length from the mirror surface to the photodiode. R was then measured by hand over the optics table, and estimated to the best of our ability using the accurate autocad drawings of ETMY. This provided us with an R length of 1.76 ± 0.02 meters. 

     Image above shows the current system in place for converting the photodiode counts into microradians. The calibration constant is implemented at the last green filter boxes for pitch and yaw. 

Lastly, to calculate the callibration constants, a series of tests were run on the ETMY suspeneded mirror. First, a time averaged value of the photodiode counts was taken with the mirror locked in place. Next, pitch and yaw were adjusted by 10 counts seperately, and the photodiode outputs recorded. This was done again but by moving the mirror 50 counts in pitch and yaw (seperately). The final result of the difference of the calculated theta values over the difference of pitch or yaw counts provided the following callibration constants:

      Pitch moved +10 counts: 131 ± 5 cts/urad

      Pitch moved +50 counts: 155 ± 5 cts/urad

      Yaw moved +10 counts: 237 ± 5 cts/urad

      Yaw moved +50 counts: 241 ± 5 cts/urad

Given our results, we believe that the values found for our 50 count translation to be the best approximation of the calibration constant due to its movement being more significant than that of the change seen from adjusting yaw or pitch by only 10 counts. 

Next steps will be to update the values in the controls system and improve the python script to be more autonomous rather than a a step by step calculation. 

After much hassle, the Guralp cable from the ADC Out of the breakout box to the ADC is fixed, and everything is plugged in and working again.  The seismometers are back in their regular positions at the ends of the MC, ready for some excellent seis/MC combo data. 

I solidified the change of putting the Gur2Z channel into a different BNC input on the ADC.  The C1ADCU_PEM.ini file has been changed so that what used to be the Ranger's channel is now recognized as Gur2Z. 

Also, I changed the same .ini file to reflect Koji's move of ACC_MC1_Z to the old AUDIO_MIC2 channel, so now all 6 Accelerometer channels have the same calibrations again.

Another big change is the change from old-left-handed convention to new-right-handed convention.  The seismometers are aligned the same way they always have been (with the North-South markers aligned with the MC), but now the North-South output is plugged into the BNC on the ADC that is associated with Gur*_X, and the East-West output is plugged into the ADC channel associated with Gur*_Y.  This is true for both Guralp Seismometers. 

So, now we have:

Gur1_X = Gur1_NS = ADC#10

Gur1_Y = Gur1_EW = ADC#11

Gur1_Z = Gur1_Vert = ADC#12

Gur2_X = Gur2_NS = ADC#2

Gur2_Y = Gur2_EW = ADC#3

Gur2_Z = Gur2_Vert = ADC#24

SEIS_Ranger_Y = no longer in the .ini file

I dedicated my evening to trying to get the Ygreen beatnote (the idea being to then get the Xgreen beatnote).

First up was tweaking up the green alignment.  Per Yuta's suggestion, elog 8283, I increased the refl PD gain by 2 clicks (20dB) to keep the lock super stable while improving the alignment.  After I finished, I turned it back to its nominal value.  I discovered that I need lenses in front of the DC PD (for Ygreen, and I'm sure Xgreen will be the same).  The beam is just barely taking up the whole 2mm diode, so beam jitter translates directly to DC power change measured by the diode.  I ended up going just by the green transmission camera for the night, and achieved 225uW of Ygreen on the PSL table.  This was ~2,000 counts, but some of the beam is always falling off the diode, so my actual counts value should be higher after installing a lens. 

I then opened up the PSL green shutter, which is controlled by the button labeled "SPS" on the shutter screen - I will fix the label during some coffee break tomorrow.  Using my convenient new PSL green setup, removing the DC PD allows the beam to reflect all the way to the fuse box on the wall, so you can check beam overlap between the PSL green and the arm green at a range of distances.  I did this for Ygreen, and overlapped the Ygreen and PSL green. 

I checked the situation of the beat cabling, since Jamie has the beatbox out for whitening filter modifications tonight.  In order to get some signal into the control room, I connected the output of the BBPD amplifier (mounted on the front of the 1X2 rack) directly to the cable that goes to the control room.  (As part of my cleanup, I put all the cables back the way I found them, so that Jamie can hook everything back up like normal when he finishes the beatbox.) 

I then started watching the signal on the 8591E analyzer, but didn't magically see a peak (one can always hope....).

I decided that I should put the offset in the Y AUX laser slow servo back to the value that we had been using for a long time, ~29,000 counts.  This is where things started going south.  After letting that go for a minute or two, I thought to go check the actual temperature of the laser head.  The "T+" temperature on the controller read something like 42C, but the voltmeter which reads a voltage proportional to the temp (10C/V) was reading 5.6V.  I immediately turned off the offset, but it's going to take a while for it to cool down, so I'll come back in the morning.  I want the AUX laser to be something like 34C, so I just have to wait.  Ooops.

Still to do (for the short-term FPMI):

* Find Y beatnote.

* Align Xgreen to the arm - it's still off in pitch.

* Align Xgreen and PSL green to be overlapped, hitting the BBPD.

* Find the X beatnote.

* Reinstall the beatbox.

* Use ALS to stabilize both arms' lengths.

* Lock MICH with AS.

* Look at the noise spectrum of AS - is there more noise than we expect (Yuta and Koji saw extra noise last summer), and if so, where does it come from?  Yuta calculated (elog 6931) that the noise is much more than expected from just residual arm motion.

* Write a talk.

Summary:

Every new year (on Dec 31 or Jan 1), all of the realtime models will report a "0x4000" error. This happens due to an offset to the GPStime driver not being updated. Here is how this can be fixed (slightly modified version of what was done at LASTI).

Steps to fix the DC errors:

1. ssh into FB machine. 
2. Edit the file /opt/rtcds/rtscore/release/src/include/drv/spectracomGPS.c:
   • Look for the code block with a text string that reads something like

     /* 2019 had 365 days and no leap seconds */
                  pHardware->gpsOffset += 31536000;

   • Copy and paste the above string for the appropriate number of years of offset you are adding, and edit the comment string appropriately!.
3. Navigate to /opt/rtcds/rtscore/release/src/drv/symmetricom. Run the following commands:

   sudo make
   sudo make install

4. Stop all the daqd processes and reload symmetricom:

   sudo systemctl daqd_* stop
   sudo modprobe -r symmetricom
   sudo modprobe symmetricom

5. Re-start the daqd processes:

   sudo service daqd_* start

Independent of this, there is a 1 second offset between the gpstimes reported by /proc/gps and gpstime. However, this doesn't seem to drift. We had effected a static offset to correct for this in the daqd config files, and it looks like these do not need to be updated on a yearly basis. All the daqd indicators are now green, see Attachment #1.

Just as predicted, all realtime models reported "0x4000" error. Read the parent post for more details. I fixed this by following the instructions. I add folowing lines to the file /opt/rtcds/rtscore/release/src/include/drv/spectracomGPS.c in fb1:

Then is made the package and reloaded it after stoping the daqd services. This brought back all the fast models except C1SUS2 models which are in red due to some other reason that I'll investigate further.

Just restarting all the c1sus2 models fixed the issue. (Attachment 1)

SUS2 ADC1 CH21 is saturated. I'm not yet sure if this is the electronics issue or the ADC issue.
SUS2 ADC1 CH10 also has large offset. This should also be investiagted.

Every year some changes need to be done manually in a driver c code file for daqd to work. The gpstime offset needs to be changed on fb for some package.

We followed the procedure on this thread, but this year it did not work. Here is a summary of our findings:

We first confirmed this is indeed the issue by doing:

This is clearly wrong gpstime. We went to the file /opt/rtcds/rtscore/release/src/include/drv/spectracomGPS.c in fb1 and added following lines after line 110:

After this, we went to  /opt/rtcds/rtscore/release/src/drv/symmetricom and ran:

We don't know how to deal with these error messages. This did not happen last year, so this might have to do with the change in fb1 or our cds setup. Chris and/or Jamie, please help.

This whole procedure is no longer needed after the CDS upgrade.  We don't do things in the old hacky way anymore.  The gpstime kernel module does not need to be hacked anymore, and it *should* keep up with leap seconds properly...

That said, there was an issue that @christopher.wipf id'd properly:

• The front end models were not getting the correct GPS time because the offset on their timing cards was off by a year.  This is because the timing cards do not get the year info from IRIG-B, so the offset they had when the models were loaded in 2022 was no longer valid as soon as the year rolled over to 2023.
• This meant that the data sent from the front ends to the DAQ was a year old, and the DAQ receiver process (cps_recv) was silently dropping the packets because the time stamps were too off.

So to resolve the issue the /usr/share/advligorts/calc_gps_offset.py program needed to be run on the front ends, and all the models needed to be restarted (or all the front ends need to be restarted).  Once that happens the data should start flowing properly.

NOTE the DAQD no longer uses the gpstime kernel module, so the fact that the gpstime module was reporting the wrong time on fb1 did not affect anything.

Anchel restarted the front ends which fixed the issue.

We got new timing hardware from Keith at LLO which will hopefully resolve the year issue (if it's ever installed) so that we won't have to go through these shenanigans again when the year rolls over.  The sites don't have to deal with this anymore.

Issues reported upstream:

•  better logging from the cps_recv process to report why there is no data coming through
•  fix packaging for advligorts-daqd to not depend on the gpstime kernel module

Also note that the code in /opt/rtcds/rtscore is completely obsolete and is not used by anything and that whole directory should be purged

Details later - empty entry for a reply.

Short story - Yend is now same as Xend filters-wise and lack of gain sliders -wise.  Both ends have 13.7k resistors around the AD620 to give them gains of ~4.5.

Xend seems fine.

Yend seems not fine.  Even the dark noise spectrum sees giganto peaks.  See Diego's elog 10801 for details on this investigation.

 [Jenne, Rana, Diego]

We did some test on the modified QPD board for the Yend; we saw some weird oscillations at high frequencies, so we went and check more closely directly within the rack. The oscillations disappear when the cable from the QPD is disconnected, so it seems something is happening within the board itself; however, looking closely at the board with an oscilloscope in several locations, with the QPD cable connected or disconnected, there is nothing strange and definitely nothing changing if the cable is connected or not. In the plots there are the usual channels we monitor, and the 64kHz original channels before they are downsampled.

Overall it doesn't seem being a huge factor, as the RMS shows at high frequencies, maybe it could be some random noise coming up, but anyway this will be investigated further in the future.

 I re-plugged in the Yend shutter, and turned it on.

 I made a Simulation with COMSOL for the Yend table. Mainly, I tried to see how the lower eigenmode changes with the number and the size of the posts inside.

The lateral frame is just sitting on the table, it is fixed by its weight. I also put a couple of screws to fix it better, but the resulting eigenfrequency didn't change so much (less than 1 Hz). 

In Fig. 1 I didn't put any post. Of course, the lowest eigenfrequency is very low (around 80 Hz).

Then I added 2 posts, one per side (Fig. 2 and Fig. 3), with different diameter.

In some cases posts don't have a base, but they are fixed to the table only by a screw. It is just a condition to keep them fixed to the table

Eventually I put 4 posts, 2 per side. 

The lowest eigenfrequency is always increasing.

At the end I also put a simulation for 4 1.6 inch diameter posts without base, and the eigenfrequency is slightly higher. I want to check it again, because I would expect that the configuration shown in Fig.5a could be more stable.

P.S.: All the post are stainless steel.

In light of the Yend auxiliary laser's ill health, I think we should reconsider the possibility of changing out the Yend laser table next week.

My thinking here is that if whatever the new mode matching solution is for a replacement laser (Tara has borrowed our spare NPRO that used to sit on top of the fridge, or we could take Annalisa's) requires a rework of the table layout, we might as well put the new layout onto the new table.  So, we need to figure out what laser we will put in as the new Ygreen, and what it's waist looks like.  If it just requires a small movement of existing lenses or new lenses in similar positions to the current ones, we can keep living with our current table.  But, if the mode matching solution requires enough changes to distances / lens placement / whatever, we should think seriously about putting in the new table next week.

Here's what I would like to see happen on / before Monday:

Annalisa - Mode matching solution for new laser.  If we get the laser back from Tara, this will involve first measuring the waist, otherwise we already know the waist of the ABSL laser that Annalisa is currently using.

Annalisa and Steve - Find optics for new mode matching in the lab, or order them by Monday afternoon.

Manasa - List of every screw, washer, optic, mount, etc. that will go on the new Y end table, with a notation as to whether or not we have it in-hand, and if not, what needs to happen before we do.  Also, for things that we don't have, I'd like to see a summary of temporary solutions (e.g. keep using current mount for doubling crystal while new one is being machined).

Manasa / Annalisa / Koji - will the new mode matching solution fit within the existing layout, or do we need to redo the table layout?

Zach has just replied, and said that we should feel free to take the laser from his iodine setup in the West Bridge subbasement, in the ATF lab. 

Annalisa, please ask Koji or Tara to show you where it is, and help you bring it to the 40m.  You should install it (temporarily) on the PSL table, measure the waist, and find the beat in IR.  Elog 3755 and elog 3759 have some of the details on how it has been done in the past.

 Ok, I'm going to contact Koji.

1) Annalisa is going to start  working on mode profiling and beat note search for the old MOPA NPRO.

2) In the meantime, Manasa is working on the end table items. This will be reviewed by KA in the afternoon.

The laser at ATF is moved to the 40m when the status of 1) and 2) is determined by KA to be reasonable.

We also make the beat note measurement for the ATF laser too.
 

Today I installed mirrors to steer the pick-off from the main laser beam in a more free part of the PSL table and make the beat note measurement between it and the NPRO.

At the beginning I took the beam from the harmonic separator after the doubling crystal, and I was going to bring it in a less full part of the table . At the end I realized that there was already a beam steered up to a more free part of the table, and the beam is taken from the transmission of the PMC.

Tomorrow I'm going to use that beam to find the beat note with the NPRO.

I also removed almost all the steering  optics that I used on the ITMY table to send the auxiliary beam for ABSL through the window parallel to the POY beam. The most important thing is that I removed the BS, which was on the same path of the POY beam (see elog 8257).

[Jamie, Jenne, Manasa]

Yesterday's goal was to get the input beam centered on the PRM, the BS and ETMY simultaneously. 

Steve helped us remove the ETMY door first thing in the morning.  We then iterated with TT1, MMT1 and TT2 to try to get the beam centered on all the optics.  We were using MMT1 instead of TT1 for a while, so that we could keep TT1 in the center of its range, so that we had more range to use once we pump down.  Also, at one point, the beam was high on PRM, centered on BS, and high on ETMY, so Jamie poked PR3 a little bit.  This helped, although we closed up for lunch / group meeting soon after, so we didn't finalize any alignment stuff.

We decided to leave the rest of the full IFO alignment alone until after the PRM-flat test.

As discussed at the meeting, I decided to effect a satellite box swap for the misbehaving MC1 unit. I looked back at the summary pages Vmon for the SRM channels, and found that in the last month or so, there wasn't any significant evidence of glitchiness. So I decided to effect that swap at ~4pm today. The sequence of steps was:

• SRM and MC1 watchdogs were disabled.
• Unplugged the two satellite boxes from the vacuum flanges.
• For the record: S/N 102 was installed at MC1, and S/N 104 was installed at SRM. Both were de-lidded, supposedly to mitigate the horrible thermal environment a bit. S/N 104 was the one Koji repaired in Aug 2019 (the serial number isn't visible or noted there, but only one box has jumper wires and Koji's photos show the same jumper wires). In June 2020, I found that the repaired box was glitching again, which is when I swapped it for S/N 102.
• After swapping the two units, I re-enabled the local damping on both optics, and was able to re-lock the IMC no issues.

One thing I was reminded of is that the motion of the MC1 optic by controlling the bias sliders is highly cross-coupled in pitch and yaw, it is almost diagonal. If this is true for the fast actuation path too, that's not great. I didn't check it just now.

While I was working on this, I took the opportunity to also check the functionality of the RF path of the IMC WFS. Both WFS heads seem to now respond to angular motion of the IMC mirror - I once again dithered MC2 and looked at the demodulated signals, and see variation at the dither frequency, see Attachment #1. However, the signals seem highly polluted with strong 60 Hz and harmonics, see the zoomed-in time domain trace in Attachment #2. This should be fixed. Also, the WFS loop needs some re-tuning. In the current config, it actually makes the MC2T RIN worse, see Attachment #3 (reference traces are with WFS loop enabled, live traces are with the loop disabled - sorry for the confusing notation, I overwrote the patched version of DTT that I got from Erik that allows the user legend feature, working on getting that back).

No exciting progress today.  I did PSL green alignment for the Yarm, although I now think that the Xarm green needs realigning too.

Also, I was foiled for a while by ETMX jumping around.  I think it's because the adapter board on the Xend rack didn't have any strain relief.  So, I zip tied the heavy cable in a few places so that it's no longer pulling on the connector.  Hopefully we won't see ETMX misbehaving as often now, so we won't have to go squish cables as often.

Yoichi's final words on what do next with the interferometer (as of 5 PM on May 21, 2009):

1. Measure laser noise couplings in spring and anti-spring configurations.
2. Dewhitening filter turn on for the ETMs.
3. Noisebudget - import from the sites.
4. Stabilize CM handoff.

My personal sub-comments to these bullets:

1. For the laser noise I'm not sure that we will be able to understand these if the couplings are mainly from junk light due to accidental HOM resonances.
2. WE should look into putting a static passive stage of filtering into the ETMs if warranted by the NB.
3. Because of the sad track record with this, I will start us off this time by importing and modifying the H1/L1 versions.
4. I guess we can do this by just acquiring on MC2 with the huge CARM offset. It works for the single arm so it should work for offset CARM.

Our visiting graduate student Yuta Michimura received 40m specific basic safety training today.

Initially I was using RFPD-1611to get the IR beat frequency. Its gain was not very high, so I was getting a very low signal of power -37 dBm.

I used ZHL-32A-S with a gain of 25 dBm to amplify it before feeding it into the spectrum analyser.

I connected the ground of the amplifier circuit to the red of the power supply, which blew the amplifier.

I learnt that there is a small tab indicating the ground side of the BNC to banana connectors which I should have noticed.

I learnt to plug in the side with th little tab on it into the ground of the power supply. (Learnt it the hard way I guess!!)

and so it begins...until this is finished I have turned off the projector and moved the striptools to the big TV (time to look for Black Friday deals to replace the projector with a 120 inch LED TV)

the upgrade seems to have been successfully executed - the machine was restarted at ~430pm local time. Projector remains off and diagnostic striptools are on the samsung.

Updated IOO.strip on Zita to show WFS2 pitch and yaw trends (C1:IOO-WFS2_PIY_OUT16 and C1:IOO-WFS2_YAW_OUT16) and changed the colors slightly to have all pitch trends in the yellow/brown band and all yaw trends in the pink/purple band.

No one says, "Here I am attaching a cool screenshot, becuz else where's the proof? Am I right or am I right?"

Mon May 24 18:10:07 2021 [Update]

After waiting for some traces to fill the screen, here is a cool screenshot (Attachment 1). At around 2:30 PM the MC unlocked, and the BS_Z (vertical) seismometer readout jumped. It has stayed like this for the whole afternoon... The MC eventually caught its lock and we even locked XARM without any issue, but something happened in the 10-30 Hz band. We will keep an eye on it during the evening...

Tue May 25 08:45:33 2021 [Update]

At approximately 02:30 UTC (so 07:30 PM yesterday) the 10-30 Hz seismic step dropped back... It lasted 5 hours, mostly causing BS motion along Z (vertical) as seen by the minute trend data in Attachment 2. Could the MM library have been shaking? Was the IFO snoring during its afternoon nap?

     It took at least ten years to rust away.

We have no coffee machine.

We are dreaming about it

We still do not have it.

New all organic machine.

On Friday, I grabbed the Zurich Instruments HF2LI lock-in amplifier and brought it home. As time permits, I will work towards developing a similar readout script as we have for the SR785.

I returned the Zurich Instruments analyzer I borrowed some time ago to test out at home. It is sitting on first table across from Steve's old desk.

Summary of the ELOGS

3f modulation cancellation theory http://nodus.ligo.caltech.edu:8080/40m/11005

3f modulation cancellation adjustment setup http://nodus.ligo.caltech.edu:8080/40m/11029

Experiment http://nodus.ligo.caltech.edu:8080/40m/11031

Receipe for the 3f modulation cancellation http://nodus.ligo.caltech.edu:8080/40m/11032

Modulation depth analysis http://nodus.ligo.caltech.edu:8080/40m/11036

I wonder if DRMI can be locked on 3f using this lower 55 MHz modulation depth. It seems that PRMI should be unaffected, but that the 3*f2 signals for SRCL will be too puny. Is it really possible to scale up the overall modulation depths by 3x to compensate for this?

This KTP crystal has the maximum allowed RF power of 10W (=32Vpk) and V_pi = 230V. This corresponds to the maximum allowed
modulation depth of 32*Pi/230 = 0.44. So we probably can achieve gamma_1 of ~0.4 and gamma_2 of ~0.13. That's not x3 but x2,
so sounds not too bad.

Then Kiwamu's triple resonant circuit LIGO-G1000297-v1 actually shows the modulation up to ~0.7. Therefore it is purely an issue
how to deliver sufficient modulation power. (In fact his measurement shows some nonlinearity above the modulation depth of ~0.4
so we should keep the maximum power consumption of 10W at the crystal)

This means that we need to review our RF system (again!)

- Review infamous crazy attn/amp combinations in the frequency generation box.
- Use Teledyne Cougar ampilfier (A2CP2596) right before the triple resonant box. This should be installed closely to the triple resonant box in order to
minimize the effects of the reflection due to imperferct impedance matching.
- Review and refine the triple resonant circuit - it's not built on a PCB but on a universal board. I think that we don't need triple
resonance, but double is OK as the 29.5MHz signal is small.

We want +28V supply at 1X1 for the Teledyne amp and the AOM driver. Do we have any unused Sorensen?

Rana showed me that if c1sus machine runs c1mcs stuff(and c1x02 stuff) only, we can use dataviewer without crashing fb.
Also, if we set correct NDS server and port(fb/8088), we can use diaggui on every machine.


During my investigation on what he did, I accidentally deleted daqd......
I am very very sorry.

I don't know if it helps or not, but all I have is the following information:

[Backup?]
    /opt/rtcds/caltech/c1/target/fb/daqd.25sep10

[What I deleted]
   -rwxr-xr-x 1 controls controls 6583071 Oct  1 11:57 daqd

[help message for daqd existed]
CDS Data Acquisition Server, Frame Builder, version 2.0
California Institute of Technology, LIGO Project
Client communication protocol version 11.4

Usage:
        daqd [-f <input frame file name>]
        [-c <configuration file (default -- $HOME/.daqdrc)>]

        [-s <frame writer pause usec (default -- 1 sec)>]


This executable compiled on:
        Fri Oct  1 10:33:18 PDT 2010
        Linux fb 2.6.34.1 #7 SMP Fri Sep 24 14:09:53 PDT 2010 x86_64 Dual-Core AMD Opteron(tm) Processor 8220 AuthenticAMD GNU/Linux


Please help me, Joe.

Problem:

Missing daqd file, i.e. the framebuilder executable.

Solution:

1) Go to /opt/rtcds/caltech/c1/core/advLigoRTS/

2) Look in the Makefile for a likely build suspect.  In this case it was build dc, which stands for data concentrator.

3) So we ran "make dc"

4) Go to the sub-directory build/dc/ and then copy the daqd file there to the /opt/rtcds/caltech/c1/target/fb directory

5) Test it to ensure we're getting channels (Yay!)

Future Safeguards:

Place the new target directory under SVN control.

c1x01 timing issue was solved. Now all of the models on c1iscex are nicely running.

Symptons

- c1x01 was synchronized to 1PPS in stead of TDS

- C1:DAQ-DC0_C1X01_STATUS (Upper right indicator) was red. The bits were 0x4000 or 0x2bad.
  C1:DAQ-DC0_C1X01_CRC_SUM kept increasing

 - c1scx, c1spx, c1asx could not get started.

Solution

- login to c1iscex "ssh c1iscex"

- Run "sudo shutdown -h now"

- Walk down to the x end rack

- Make sure the supply voltages for the electronics are correct (See Steve's entry)

- Make sure the machine is already shutdown.

- Unplug two AC power supply of the machine.

- Turn off the front panel switch of the IO chassis

- Wait for 10sec

- Turn on the IO chassis

- Plug the AC power supply cables to the machine

- Push the power switch of the realtime machine