(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

When I finished my measurements, the modulation setup was reverted to the conventional one.
If someone wants to use the 3f cancellation setting, it can be done along with this HOW-TO.

The 3f cancellation can be realized by adding a carefully adjusted delay line and attenuation for the 55MHz modulation
on the frequency generation box at the 1X2 rack.  Here is the procedure:

1) Turn off the frequency generation box

There is a toggle switch at the rear of the unit. It's better to turn it off before any cable action.
The outputs of the frequency generation box are high in general. We don't want to operate
the amplifiers without proper impedance matching in any occasion.

2) Remove the small SMA cable between 55MHz out and 55MHz in (Left arrow in the attachment 1).

According to the photo by Alberto (svn: /docs/upgrade08/RFsystem/frequencyGenerationBox/photos/DSC_2410.JPG),
this 55MHz out is the output of the frequency multiplier. The 55MHz in is the input for the amplifier stages.
Therefore, the cable length between these two connectors changes the relative phase between the modulations at 11MHz and 55MHz.

3) Add a delay line box with cables (Attachment 2).

Connect the cables from the delay line box to the 55MHz in/out connectors. I used 1.5m BNC cables.
The delay line box was set to have 28ns delay.

4) Set the attenuation of the 55MHz EOM drive (Right arrow in the attachment 1) to be 10dB.

Rotate the attenuation for 55MHz EOM from 0dB nominal to 10dB.

5) Turn on the frequency modulation box

For reference, the 3rd attachment shows the characteristics of the delay line cable/box combo when the 3f modualtion reduction
was realized. It had 1.37dB attenuation and +124deg phase shift. This phase change corresponds to the time delay of 48ns.
Note that the response of a short cable used for the measurement has been calibrated out using the CAL function of the network analyzer.

Huge random numbers are flowing into ETMX/ETMY ASC PIT/YAW. Because of this, I could not damp the ETMX/ETMY suspension at the beginning during the recovery from rebooting. (Attachment 1)
By turning off the output of the ASC filters, the mirrors were successfully damped.

Looking at the FE model view of the end RTSs, there were two possibilities: (Attachment 2)

- They are coming from RFM connection
- They are coming from ASXASY

ASX/ASY are not active and I could not see anything producing these numbers. Burtrestore didn't help.

The possibility was something at the other side of the RFM, or corruption of the RFM signal.

- Looking at the RFM model (Attachment 3), the ASC signals are coming from ASS and IOO. The ASS path has the filter module (C1:RFM-ETMX_PIT and etc). This FM is quiet and not guilty.

- Why do we have the RFM from IOO? I went to IOO and found the new ASC (WFS) model is there. I didn't realize the presence of this model. In fact ASC screen showed that these random numbers are flowing into the end SUSs.
So I did burtrestore of c1iooepics. Alas! they are gone.

Now I can go home.

Yeah, this is a known issue actually. We go to ASC screen and manually swich off all the outputs after every reboot. We haven't been able to find a way to set default so that when the model comes online, these outputs remain switched off. We should find a way for this.

you can hand edit the autoBurt file which the FE uses to set the values after boot up. Just make a python script that amends all of the OFF or ZERO that are needed to make things safe. This would be the autoBurt snap used on boot up only, and not the hourly snaps.

The autoBurt file for FE already has the C1:ASC-ETMX_PIT_SW2 (and other channels for ETMY, ITMX, ITMY, BS and for YAW) present, and I checked the last snapshot file from Feb 7th, 2022, which has 0 for these channels. So I'm not sure why when FE boots up, it does not follow the switch configuration. Fr safety, I changed all the gains of these filter modules, named like C1:ASC-XXXX_YYY_GAIN (where XXXX is ETMX, ETMY, ITMX, ITMY, or BS , and YYY is PIT or YAW) to 0.0. Now, even if the FE loads with switches in ON configuration, nothing should happen. In future, if we use this model for anything, we can change the gain values which won't be hard to track as the reason why no signal moves forward. Note, the BS connections from this model to BS suspension model do not work.

This did the trick - I simply ran

on FB1, and now all the CDS overview lights are green again.

I thought I had done this already, but I realize that I was supposed to restart the daqd processes on FB1 (which is where they are running) and not on c1ioo .

Thanks Jamie for the speedy resolution!