Possible explanations:

• The data transfers to LDAS had been shut off while we were doing the DAQ debugging. I don't know if they have been turned back on.  Unlikely this is the problem since you would probably see no data at all if this were the case.
• wiper script parameters might have been changed to store less of the trend data for some reason.
• Frame size is different and therefore wiper script parameters need to be adjusted.
• Steve deleted it all.
• ...

c1lsc had 60 full-rate (16kS/s) channels to record. This yielded the LSC to FB connection to handle 4MB/s (mega-byte) data rate.
This was almost at the data rate limit of the CDS and we had frequent halt of the diagnostic systems (i.e. DTT and/or dataviewer)

Jenne and I reviewed DAQ channel list and decided to remove some channels.  We also reviewed the recording rate of them
and reduced the rate of some channels. c1lsc model was rebuilt, re-installed, and restarted. FB was also restarted. These are running as they were.
The data rate is now reduyced to ~3MB nominal.

The following is the list of the channels removed from the DQ channels:

AS11_I_ERR
AS11_Q_ERR
AS165_I_ERR
AS165_Q_ERR
POP55_I_ERR
POP55_Q_ERR

The following is the list of the channels with the new recording rate:

TRX_SQRTINV_OUT 2048
TRY_SQRTINV_OUT 2048
DARM_A_ERR 2048
DARM_B_ERR 2048
MICH_A_ERR 2048
MICH_B_ERR 2048
PRCL_A_ERR 2048
PRCL_B_ERR 2048
CARM_A_ERR 2048
CARM_B_ERR 2048

I was trying to plot trends (min, 10 min, and hour) in DataViewer and got the following error message

Connecting.... done
 mjd = 58235
leapsecs_read()
  Opening leapsecs.dat
  Open of leapsecs.dat failed
leapsecs_read() returning 0
frameMemRead - gpstimest = 1208844718
 

thoough the plots showed up fine after. Do we need to fix something with the leapsecs.dat file?

Summary:

The database files for C1ISCAUX seem to work file - the exception being the mbbo channels for the CM board.

Details:

This was just a software test - the actual functionality of the channels will have to be tested once the Acromag crate has been installed in the rack. One change I had to make on the MEDM screen for the LSC PD whitening gains was to get rid of the "NMS" suffix on the EPICS channel names for whitening gain sliders/drop-down-menus. I suspect this has to do with the EPICS version we are using, 7.0.1. Furthermore, AS165 and POP55 no longer exist - I hold off removing them from the MEDM screen for the moment.

Next steps:

From the software point of view, the major steps are:

1. Fix the mbbo channel notation in the database files
2. Write and test the latch enabling code
3. Figure out what scripted tests can be done to test the functionality of the new Acromag box.

I am stopping the EPICS server on the new machine and restarting the old VME crate over the weekend.

I completed the translation of the .db files for the EPICS database records from the VME notation to the Acromag/Modbus/Asyn notation. The channels are now organized into 5 database files, located in /cvs/cds/caltech/target/c1iscaux3/,  for convenience:

1. C1_ISC-AUX_LSCPDs.db -------- This handles whitening gain, AA enable/bypass, Demodulator FE, and PD Interface Board channels for REFL11, REFL55, REFL33, REFL165, POP22, POP110, POX11, POY11, AS55 and AS110 photodiodes.
2. C1_ISC-AUX_CM.db -------------- This handles all channels for the CM board. The mbbo addressing notation needs to be checked.
3. C1_ISC-AUX_QPDs.db ----------- This handles all channels for the IPPOS QPD.
4. C1_ISC-AUX_ALS.db ------------- This handles all channels for the IR ALS DFD LO and RF power monitoring.
5. C1_ISC-AUX_SPARE.db ---------- This handles the unused channels for the various whitening, AA and PD interface boards.

For reasons unknown to me, the database files in the other Acromag system target directories (e.g. c1susaux, c1auxex) all had 755 level access permission - maybe this is required for systemctl to handle the EPICS serving? Anyways, I upgraded the permission level of the above 5 files using chmod.

There are almost certainly typos / other errors, and I may have missed copying over some soft/calibrated channels, but I hope that this way of grouping by subsystem will make the debugging less painful. Once Chub connects up the power lines to the Acromags, I will run the soft tests. For this purpose, I've also made a C1_ISC-AUX.cmd file and a C1_ISC-AUX.env file in the above target directory, and also made the modbusIOC.service file in /etc/systemd/system on the supermicro.

Dataviewer x axis end is not there.

On ( 2600 days) longer plots it is missing 8 moths and on (100 days) shorther plot it is missing 1 month.

Masayuki pointed out that dataviewer wasn't connecting to the fb this morning.

When I started dataviewer from the terminal I obtained the following error:

controls@pianosa:~ 0$ dataviewer
Can't find hostname `fb:8088'
Can't find hostname `fb:8088'; gethostbyname(); error=1
Warning: Not all children have same parent in XtManageChildren
Warning: Not all children have same parent in XtManageChildren
Warning: Not all children have same parent in XtManageChildren
Warning: Not all children have same parent in XtManageChildren
Warning: Not all children have same parent in XtManageChildren
Error in obtaining chan info.
Can't find hostname `fb:8088'
Can't find hostname `fb:8088'; gethostbyname(); error=1

I checked the CDS FE status screen and it looks normal. I could ping the fb and ssh to it as well.

I restarted fb to see if it made any difference. telnet fb 8088

It hasn't helped. Anything else that can be done??

I've fixed the problem.  This was due to a change I made in the NDSSERVER environment variable so that it would work with cdsutils.  I didn't realize there was an incompatibility with how dataviewer parses NDSSERVER.  Joe and I will have to figure it out.

In the mean time I've changed things back so that that dataviewer should now work as expected.  You might have to log out and back in for it to work (or at least open a new terminal).

I'm not able to get trends of the TM adjustment test that Rana had asked us to perform, from the dataviewer. It's throwing the following error:

Connecting to NDS Server fb (TCP port 8088)
Connecting.... done
Server error 7: connect() failed
datasrv: DataWrite failed: daq_send: Resource temporarily unavailable
T0=19-07-20-01-27-39; Length=600 (s)
No data output.

What channels are you trying to read?

 I have modified the Dataviewer launcher (which runs when you either click the icon or type "dataviewer" in the terminal).  

A semi-old problem was that it would open in the file /users/Templates, but our dataviewer templates start in /users/Templates/Dataviewer_Templates.  Now this is the folder that dataviewer opens into.  This was not related to the upgrade to Ubuntu 12, but will be overwritten any time someone does a checkout of the /ligo/apps/launchers folder.

A problem that is related to the Ubuntu 12 situation, which we had been seeing on Ottavia and Pianosa for a few weeks, was that the variable NDSSERVER was set to fb:8088, which is required for cdsutils to work.  However, dataviewer wants this variable to be set to just fb.  So, locally in the dataviewer launcher script, I set NDSSERVER=fb.  NB: I do not export this variable, because I don't want to screw up the cdsutils.  This may need to be undone if we ever upgrade our Dataviewer.

Q adjusted the Dataviewer so it is not chopping of data any more. Thanks.

Cold cathode gauge reading of 10 years.

Using one of the prototype PCB boards given to me by Johannes, I put together v1 of this board and tested it. 

Attachment #1 - Schematic with stages grouped by function and labelled. 

Attachment #2 - Measured vs modelled Transfer function.

Attachment #3 - Measured vs modelled noise. Measurement shown only between positive output and ground, the other port is basically the same. I will update this attachment to reflect the expected signal level in comparison to the noise, but suffice it to say that given the measured input referred noise, we will have plenty of SNR between 0.1Hz and 10kHz. The single stage of whitening should also be sufficient to amplify the signal above ADC noise in the same frequency band

Attachment #4 - Positive output as viewed on a fast (300 MHz) scope using a Tektronix x1 voltage probe.

Attachment #5 - Daughter board noise with measured ALS noise overlaid (the gain of x10 on the existing audio pre-amp has been divided out). 

Comments:

• I may have overlooked the GBW of the OP27 in the design - specifically, the negative feedback is wired for gain x100 at high frequencies, and so the input signal should be filtered above 8MHz/100 ~80kHz. But the LC poles are at ~500kHz. I wonder if the small deviation seen between modelled and masured TFs is reflecting this. Practically, the easier fix is to add a feedback capacitor that rolls off the gain at high frequencies. 300pF WIMA should do the trick, and we have these in stock.
• I don't understand why the modelled response starts to roll off around 5kHz, even though the poles of the LC filter at the input stage are at 500kHz. This happens because at low frequencies, the 1.5uH inductor is basically a short - so the RC divider at the input of the Op27 has a pole at 1/2/pi/R/C ~5kHz for R=499, C = 68nF.
• I am not sure what to make of the peaky comb seen in Attachment #3, but I'm pretty sure it's electronic pickup from something. The GPIB adapter power suppy is not to blame. The peaks are 10 Hz spaced.
• From Attachment #4, I don't suspect any opamp oscillations given that the signal seen is tiny, but I don't know what amplitude is characteristic of an oscillating op amp, so I am not entirely confident about this conclusion. 
• Initially while thinking about the design, I was trying to think of making the design generic enough that we could use these signals for high-bandwidth ALS control (a.k.a. Fast ALS) but in the current incarnation, no consideration was given to minimizing phase lag at high frequencies. 
• Putting the PCB board together was more painful than I imagined as the board is configured for 4 single op amps whereas my design requires 5 - so I needed to do some trace cutting surgery. Rather than make 3 more of these, I'm just going to finish the characterization, and if the design looks good, we can get some custom PCBs printed.
• Power decoupling caps (47nF) are added to all op amp power pins, but is not shown in the schematic.

Given the overall good agreement between model and measurement, I am going to test this with the actual RF beat. For this test, we will need a differential receiving AA board to interface the output of the daughter board with the ADC input. 

Looks good.

* for bypass type applications, you don't have to use Wima caps (which are bigger and more expensive). You can just use any old ceramic SMD cap.

* This seems like a classic case to use the 3 op-amp instumention amplifier config. This is similar, but not quite.

* Ought to use output resistors of ~50 Ohms by default in the output of any circuit. SInce this is a daughter board, maybe 10 Ohms is enough, but the eventual PCB should have pads for it.

I thought a little bit about the next steps in testing the daughter board. The idea is to install this into the existing 1U chassis and tap the differential output from the FET Mixers as inputs to the daughter board. Looking at the D0902745 schematic, I think the best way to do this is to simply remove L3, L4, C10, C11, C15 and C16. I will then use the pads for L3 and L4 to pipe the differential output of the FET mixer to the differential input of the daughter board. 

The daughter board takes care of whitening the ALS signal.

Then we need to pipe the differential output of the daughter board into the differential input of a differential receiving AA board. Koji and Johannes surveyed the available stockpile from the WB workshop. The best option seems to be to use the available v5 of D070081 and install 4 of them into a 1U chassis unit (also available from WB EE shop). The v5s can be upgraded to v6 by replacing the set of input and output buffer OpAmps with AD8622, as per the revision history notes. Koji ordered 100pcs of these today. 

The input to the proposed 1U chassis housing these 8 AA boards (each with 8 channels) is a DB9 connector. The aLIGO demod board chassis that we use to demodulate the ALS signals has a nice DB25 output connector that supplies all the differential I and Q demodulated signals. But since we will install a daughter board, we will hae to hack together some connector solution anyways. I propose using a DB9 connector to pipe the outputs of the daughter board to the inputs of the AA board. Space is tight in the LSC rack, but I think we have space for a 1U chassis (see Attachment #3).

Finally - how to interface the AA board with the ADC? Koji and I discussed options, and seems like the least painful way will be to install a new ADC in the c1lsc expansion chassis in 1Y3. I checked the computer hardware cabinet and there seems to be 1 spare general standards 16bit ADC in there (see Attachment #1). Its health/providence is unknown. But Koji and I will test it after the meeting tomorrow. I also have another ADC card that Jamie and I removed from c1ioo sometime ago. I have labelled it as "GPIO0 LED RED", though I don't remember exactly what the problem was and can't find any elog about it. Incidentally, there are also 2 spare DAC cards available in the cabinet, although their health/rpovidence too is unknown. There are sufficient free slots in the c1lsc expansion chassis (see Attachment #2 though we will need a LIGO ADC adaptor card). Then we can just change the input ADC channels for the ALS signals in the c1lsc model.

In the short term, while the hardware for this plan is being put together, I can test the uncalibrated noise performance of the demod + daughter board combo (uncalibrated because I will make a measurement of voltage noise with an SR785 as opposed to frequency noise). A second daughter board will also need to be assembled - I'm just going to do it on another prototyping board as figuring out how to use Altium will probably take me longer. There is also the matter of fine tuning the polarization axes alignment of the input to the EX fiber coupler.

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

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

Summary:

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

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

Measurement:

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

Results:

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

Next steps:

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

Summary:

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

Details:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[Joe, Jenne]

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

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

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

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

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

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

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

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

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

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

I was working around the PSL table today.

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

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

I was working on the PSL table today. 

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

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

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

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

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

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

[Diego, Manasa]

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

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

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

 OUTDATED: see elog 10779

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

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

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

 OUTDATED: see elog 10779

 Update and corrections:

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

Elaborate to do list:

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

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

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

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

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

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

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

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

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

RXA: later, Max sent us this secret note:

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

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

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

This must all be done from the cluster using the 40m shared account.

Pages still not working: PEM and MEDM blank.

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

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

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

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

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

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

Yes

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

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

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

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

[Den, Ayaka]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

For a delay line frequency dicriminator, the output at the mixer is proportional to  where 

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

The linear output signal canbe obtained for  

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

[Koji, Manasa]

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

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

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

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

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

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

I fit the data to  
where L - cable length asymmetry (27 cm) , f_b - beat frequency and v - velocity of light in the cable (2*10⁸ m/s)

The plot with the cosine fit is attached. 

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