I forgot to add the ADC noise. Now that I put the ADC noise there, the noise matches beautifully.

Noisemon transfer function with phase, in dB counts.

Transfer function. The simulation and the test results differs by a phase of 180 degree (attachment 3). I added 180 degree got attachment 1.

Voltage monitor test data. Theory: 20 * log(1/2 * 1/3) = -15.6dB. ~1dB less attenuation from calculation.

When we connect the voltage monitor channel of the noisemon board to a long cable (100ft), the op amp (LT1792) oscillates. Usually putting a 50 ohm resistor at the end will fix it. In this post, I studied how the oscillation happens and why putting a 50 ohm resistor will fix it.

We know 1) op amp has a dominant pole, giving a phase shift of 90 degrees 2) op amp oscillates when the loop gain is unity and the phase shift is 180 degrees. 3) Op amp has some non-zero output resistance.

Based on 3), we can see that when the output is capacitively loaded, there will be another pole in the transfer function due to the RC configuration. Since both R and C are small, it will be at high frequency (as op amp oscillations usually are). Thus, beyond the dominant pole, the phase will keep shifting to 180 degree based on 1). When this happens before the loop gain drops to unity, there will be oscillation based on 2).

Fix: insert a resistor at the output. This fixes the problem since it adds a zero with frequency a bit higher than the parasitic pole. This zero pulls the phase up so that when the loop gain reaches unity, the phase is around 90, at least far from 180, preventing oscillation from happening. The transfer function of this is simulated in LISO. From the plot, we can see the effect of the output resistance pulling the phase up to zero (90 in the case of an opamp because of the dominant pole).

Noisemon installed in ITMX at L1. I pulled the 1-coherence data. trying to compare with Valery's measurement: https://alog.ligo-la.caltech.edu/aLOG/index.php?callRep=43240.

I calculated the noise based on L1 data. My calculation is

(1-coherence) * drive = noise in DAC counts

noise in volts = noise in DAC counts * 20 / 2^16

Is this correct?

Increase avg to 1000. We are going to calculate the DAC noise from this.

L1 noisemon data for all four channels.

Plotted.

Will compare ITMX with ETMY.

Going to see if # of average makes any difference.

The formula used to calculate the noise is

Noise = Sqrt[1 - coherence] * drive

ETMY is about the same as ITMX.

More avg - more smoothiness but the shape of the noise curve is the same.

Trying to see if I can reproduce https://alog.ligo-la.caltech.edu/aLOG/uploads/43363_20190213151300_subtraction_offset.png when I use average of 10.

No. Did not reproduce it. Attachment 3 is the same plot without restrictions on the y axis range.

The result is lower when I change the window but still not the same as alog post. A factor of 2 larger at 30Hz.

The bin size was 1Hz. I changed it to 0.1Hz. Now we get some real data.

Can't tell what's going on. Pleaese make the plots readable and describe in the elog what precisely is being calculated.

The PUM noisemon board has been installed in Livingston ITMX test mass. After the installation, we fetched the coil driver drive signal, noisemon output signal and the coherence between them. 

This is how we calculate the DAC noise spectrum. The unit is V/rtHz.

The data fetching configurations are:

- Start time: 1250467218. Locked for more than 20hrs from there, if you check here: https://ldas-jobs.ligo-la.caltech.edu/~detchar/summary/day/20190822/

- Bin size: 0.1Hz

- Window: Hanning

- Average: 1000

Attachment 1 and 2: plot of the DAC noises in volts compared to the G1401399 model.

Attachment 3 and 4: plot of the DAC noises projected to the displacement of the test mass and incohrerently summed from all the four test masses.

All the data are attached as xml files. They are directly saved from DTT and can be opened in DTT.

To reproduce the plots, run the python code in the zip file. The code runs without any parameters. 

I'm attaching a script to download data from the LIGO sites with python.

I recommend using it in your anaconda3 ENV:

conda install -c conda-forge nds2-client python-nds2-client

and then before running the script you have to initialize your Kerberos token:

kinit miley.cyrus@LIGO.ORG

then you run the script:

python getData.py --ifo=L1 --fs=1024

as usual, run with the -O or -OO flags to silence the debug messages.

I don't agree about this. Doesn;t this ignore the noise of the noisemon circuit (analog readout noise + ADC noise) ? I think you must have a model for than noise in order to infer the DAC noise. Or maybe my pringle suggestion has better SNR?

I did a quick estimation of the subtraction result. I subtracted the ADC noise and the noisemon noise. 

Now I subtract it:

The ADC noise and Noisemon noise are converted to DAC volts (divided by the transfer function of the noisemon and coil driver).

Form the results from 10-200Hz, it seems that the calculated noise is DAC noise.

Attachment 2 is the result: subtracted noises vs. model compared to aLIGO noise.

Attachment 1 shows how the subtraction is done: we subtract noisemon noise from the total noise. (Noisemon noise contains ADC noise) Noisemon noise and ADC noise is neglegible at that frequency.

It seems at low frequency what we see there might still be DAC noise, if not other unknown sources.

This is the DAC noise of ITMY PUM coil driver in L1. The data is from September 25, 2019 00:00:00 UTC. I did not subtract the ADC noise and the noisemon noise since I did it for ITMX. The noisemon noise is far below the total noise, and the ADC noise only dominates high frequency. After subtraction, the mismatch above 500Hz will disappear.

There are some lines around 65Hz. I checked the data a few days arounds 9/25. I see them in all the data. I do not understand why yet.

Spectra of the PUM drive signal is attached in 3, noisemon output in 4. I do not see anything at 65Hz in those channels.

ADC noise and Noisemon noise are subtracted in attachment 5.

I checked these data

9/23 00:00, 8:00, 20:00

9/24 8:00,

9/25 0000,0800,2000

9/26 0800,2000

9/27 0000.0800.2000

10/1 0800

The 65Hz harmonics stays there.

I checked time domain for 9/15. It is not saturating. (Attachment 6&7)

Attachment 8 is a check on the output of the noisemon signal when L1 is down. It is from 9/24 1600. Surprisingly, I see the 65Hz harmonics in UL spectrum while I cannot see it when the interferometer is online. I do not see the harmonics in the other three channels.

In attachment 9, I checked ITMX from the same time (9/24 1600, interferometer down). The 65Hz harmonics is there in all channels, and the UL output is higher.

Noisemon has been installed at L1 for a while. Now we have it on ITMX and ITMY. ITMX was installed first and ITMY was installed on September 11.

Recently, after it was installed at ITMY, we were trying to check the functionality of the circuit - if it measures DAC nosie properly between 20 - 100Hz. When we were doing that, we encountered some strange harmonics of 65Hz in UL channel. It is shown in attachment 6, data from 9/25 ETMY.

We traced back to where it was installed at ETMY, 9/11, and we still see the lines there (attachment 5).

Then we went to check ITMX, since the data was consistent when it was first installed. However, when we use 9/25 data, we see attachment 4. The UL channel measurement is way above the other three channels. Tracing back the dates, we found in ITMX it started 9/10 (attachment 3), comparing to 9/9 (attachment 2) when it was still good.

All the data and scripts are in attachment 1.

Notes (in case you read about noisemon for the first time):

All the plots are

It is suppose to be DAC nosie + Noisemon noise + ADC noise, which DAC noise being dominant between 20 - 100Hz. The purple curves are DAC noise model. The measurements are expected to be close to it between 20Hz and 100Hz.

Although L1 has been down since the beginning of October, I checked the spectrum at the output of the nosiemon at L1 ITMY. It looks like the UL channel, as we have seen before, still has the lines,

I checked the October 25 data at L1. The drive signal is zero, according to the bottom plot in attachment 1 and 2. The fastimon channel has a lot of lines. Noisemon still has the 65Hz harmonics.

I also checked the Nov 7 noisemon and fastimon data. We still see the harmonics on Nov 7. Also, one channel is completely dysfunctioning. The fastimon is similar to Oct 25.

Attachment 1: Oct 25 noisemon. We still see the harmonics in the noise.

Attachment 2: Oct 25 fastimon. Two channels are messy.

Attachment 3,4,5: Nov 7 noisemon data. Analyzed in attachment 4. Data in attachment 5.

Attachment 6: Nov 7 fastimon data. Similar to Oct 25 - a lot of lines.

Noisemon has been installed in LLO ITMY station. Its LL channel starts to saturate at 10/30 00:00:00. I checked the noisemon output at that time (attachment 1).

The first noisemon board was installed at the ETMY station. It was a prototype board that we brought to LLO and installed there since then. I checked the data today (11/14) and its LL channels is not working.

I checked the time series in the attachment 2 and 3. There are some problem causing the circuit to saturate.

I checked the drive signal below 10Hz in attachment 4. The drive signals across all channels are the same.

I checked the behavior of noisemon in the three stations where they are installed. It is consistent that there is always one channels that is saturating and one channel that has excess noise. However, they are not always the same channels.

ETMY, attachment 1, LL saturating, UL excess noise (UR a little more noise)

ITMY, attachment 2, LL saturating, UL excess noise

ITMX, attachment 3, UL saturating, UR excess noise

Saturation occurs suddenly after running for hours without problem.

I tracked it since the drive was turned on (around 00:36:18) and found that it has been running ok for hours before this happens (attachment 1). Around 3:04:51, the LL channel saturated and then dropped back to normal level. After that, this kept happening and crashed the LL channel (attachment 3).

Attachment 2 is data corresponding to attachment 1.

We see a report of noisemon problem from LLO: https://alog.ligo-la.caltech.edu/aLOG/index.php?callRep=49892

The time domain data is projected with the transfer function measured here: https://alog.ligo-la.caltech.edu/aLOG/index.php?callRep=43212

We projected the output of the noisemon signal on time domain (attachment 1).

Attachment 2 is data from LLO posted in the alog above. Compare this with attachment 1, we can see our projection has roughly the same values with the other three channels. This means those channels have high number of counts because the drive signal is bigger. In other words, the other three channels should be working ok.

I attached the drive signal being projected in attachment 3.

Attachment 4 has all the data and code.

I found that two of the channels misbehaves after the board runs for a couple hours. Turning the power off and back on returns the circuit to normal functionality.

I sent 100 counts amplitude 10Hz sine into the board.

• I saw channel 4 has some bad behavior - about 3V of offset with a lot of noise and one spike goes up to saturation.

Then I switched power off and back on. It worked normally. I increase amplitude to 2500, same as Carl's 10000. It worked normally as well. However, when I came back after a couple hours,

• I saw two channels (1&4) saturates about 4 times a second. The other two still ok. (attachment 1)

 Then I turned power off and on again. I got attachment 2 - normal behavior again.

I think I shorted somewhere near the RTN testpoint on the board today while testing it. I saw some sparks. After that the board becomes non-responsive - it is not responding to whatever signal I send in. I will use another board and go on with testing.

We have observed that the noisemon bug happens after it is powered on for about 1.5 hour. Noisemon has been powered on overnight and the following morning I came in and found

- Channel 1, 3, 4 bad (with signals like attachment 1. Green: normal behavior driven with 250 count, 10Hz signal. Brown: abnormal behavior with no drive)

- Then I used the oscilliscope and did the following on channel 4:

1. Connected channel 1 to measure the voltage between one side of C2 and GND.

2. Connected channel 2 to measure the voltage between another side of C2 and GND.

3. Use MATH on the oscilliscope to measure the voltage difference

- Then I found channel 4 is good! I did not turn the power off or do anything else.

- I repeated exactly the same procedure on channel 3 and it is repeatable.

- I left channel 1 as comparison and made attachment 2.

- Then I just use the probe of oscilliscope to connect one side of C2 on channel 1 to GND and got attachment 3, which channel 1 is good again.

I think this is a very strong hint that this whole problem is due to C2 charging up.

According to previous post 1834, we think the noisemon problem is very likely caused by C2 charging. Hence we did the following modifications on a noisemon board:

1. Split R2 into two 400 Ohm resistors, with grounding between them.

2. Split C2 into two 3.3uF capacitors, with grounding between them.

We hope these modifications will provide a path for the bias current to go to ground, instead of charging up C2.

The modification is successful. The attachment shows the result after the board runs for 12 hours. We modified channel 1 and 2 so we see FM0 and FM1 channels are still decent. We only split C2 but not R2 for channel 3 and 4 so FM2 and FM3 are bad.

Fully board successful with modification. The saturation issue has been fixed on all the four channels.

I finished testing S1900294 and S1900297 and plan to ship them to the sites.

I got stuck at a couple things. I think it is good to make a note of these stuff.

1. Diaggui gives "unable to start excitation".

Solution: restart diaggui

2. Drive signal does not go in

Solution: check the status of the digital system - it crashed and needs restart.

3. FASTIMON gives too much noise that the transfer function looks like junk.

Solution: I use 50ohm resistors to replace the coils and 500 counts noise to measure the transfer function. If the resistance is large and the input signal is small, the current will be too small.

The noisemon board has been modified according to 1835. We do not expect any change in the transfer function but we see an increase in the gain above 20Hz.

Attachment 1 shows the comparison between modified board transfer function and the original board transfer function.

Attachment 3 shows the difference of the transfer functions in attachment 1. There is about 8-10dB increase at 100Hz after the modifications.

Attachment 4 is a comparison of LISO simulations. I calculated the transfer functions of the whole noisemon circuits before and after the modifications. I substracted them and found the difference.

Without putting attachment 3 and 4 in the same picture we can see that they are very different. LISO basically says there will not be any significant change in the transfer function but actually our measurement shows that there is.

I did some documentation work these days.

- Noisemon Test Plan: https://dcc.ligo.org/LIGO-E2000007

- Updated DCC, new schematics, PCB layout and BOM (due to changes logged in 1835)

- Two more boards are modified and will be tested.

I am testing another two boards to be shipped to Hanford today. I found and fixed some bad soldering. However, the frontend crashed and I needed to restart it. I could not log into cymac somehow. It says "no route to host" but the internet is still working. I cannot go on testing anymore. Let's wait and try again tomorrow.

Chris fixed the problem - I went on finishing the tests and the boards are ready to go now. They will be shipped tomorrow.

We have sent version 2 noisemon boards (modifications from version 1 noted in 1835) to Livingston and Hanford. Chris noticed that there might be some upconversion problems under 20Hz (attachment 1 and 2). These plots from Chris are noisemon output with drive subtracted. Attachment 1 is the spectrum after replacement of noisemon board (version 2 board used), compared to attachment 2 which is before the replacement (version 1 board used). There is something going on near 15Hz. We think it might be due to upconversions under 15Hz.

We still have a spare board here. I modified it, tested it and looked at this issue, trying to reproduce. I sent a 10Hz 100 count amplitude signal to the board and compared it to the output with no input. This produces attachment 3. We see that once the 10Hz sine signal is sent, there are  lines above 10Hz, which is a sign of distortion.

I changed the input frequency to 5Hz and got attachment 4.

Attachment 5 is a linear plot to see where exactly those lines are. It seems they are indeed harmonics of 5Hz when the input signal is 5Hz.

I also tried higher frequencies up to 100Hz and saw similar harmonics.

it might be the low input impedance of the board which the coil driver cannot drive..

I suggest you use probes to see where in the noisemon circuit the distortion is starting

Trying to figure out the nature of the distortion found in noisemon (1843), I made a piece of DSUB9 breakout like attachment 1. I just used two wires and two clippers wires to break the DSUB connector into something I can clip into the board.

I sent a 10Hz drive to the coil driver and measured the spectrum at all the test points (including one pair on the coil driver board).

First, I compared the distortion situation at the input and output of noisemon (attachment 2). I measured the spectrum at TP10 and TP12 of coil driver (this is where noisemon picks up the differential input, reference DCC: D070483), and subtracted them quadratically, which gives us the input signal of noisemon. Then I measured the spectrum at the output of noisemon. Looking at attachment 2, it seems the coil driver does not contribute to the distortion.

Then I used the probe and measured all the test points individually. Attachment 3 also shows TP10 and TP12 but instead of measuring them individually and subtracting them, I just put one probe on TP10 and another on TP12. It looks like the coil driver does have a little distortion, contrast to the conclusion above.

Attachment 4 shows the spectrum at the noisemon input. There is a buffer between TP10/TP12 on coil driver and the input of noisemon (reference D070483). It looks like the distortion is less, somehow.

Attachment 5 is the spectrum after the passive filters, between TP3 and TP4. It seems the distortion comes back a little under 60Hz.

Attachment 6 shows the spectrum after the instrument amplifier.

Attachment 7 and 8 shows the output of two stages of high pass filters. The distortions gets much worse after two HP filters.

Attachment 9 shows the output of the low pass filter. We can see the high frequency harmonics are gone.

Attachment 10 is very confusing. Between TP8 and TP9 is just a buffer (LT1128 buffer unfortunately) - why does it give so many lines even without any drive? I tried to see them in the oscilloscope but there wasn't anything significant. Maybe it was the clippers/wires making the noise? I did check the signal at the conjunction point between the clipper and the wire using oscilloscope (attachment 11) - it is indeed bad (attachment 12) - but why these lines only show up in TP9?

I am very confused and need to think about what is going on now. I think a couple immediate questions are:

1. Why do I see so many lines at the output of noisemon even when there is no input? I should only see noisemon noise when there is no drive, but I did not short the inputs like when I measure the noise. I did shorted the inputs and checked the noise after the measurement - it is normal. Thus, the lines could be caused by not shorting the inputs of the coil driver, but I did not short the inputs in other measurements either - I just unchecked the excitation on diaggui.

2. Besides the TP9 confusion, we still see a lot of harmonics in uppersteam testpoints. Considering the TP9 situation, I think we should first ask - are they real? Then, if they are real, how bad are they? Considerations could include the functionality of noisemon board at the sites? This potentially include risk of saturation, increase of the noisemon noise and errors in measuring the DAC noise.

I measured the spectrum with the digital system at all test points on noisemon with 10Hz sine drive (1845), but I saw a lot of distortion harmonics and other confusing stuff. At the end, I realized it could be caused by the clipper wire I used to breakout the DSUB9 connector. After talking to Chris today, I also realized that the low input impedance of the digital system could be invasive to the circuit. Considering these potential issues, I repeated yesterday's measurements with SR785 (attachment 3). There is not much difference - instead of using the digital system to send the drive and do the measurements, I used SR785 to drive and measure. SR785 has 1MOhm of input impedance while the ADC has only 10-20kOhm, according to Chris, so it could resolve the input impedance issue. Also, there is no DSUB connectors used; it also let me get rid of the clipper wires. 

I sent a 10Hz, 10mV p-p sine signal to the coil driver and measured all the test points from the output of the coil driver to the output of the noisemon. The results are in attachment 2, plotted in attachment 1. The test points can be referenced in the schematics in attachment 4. The plots with two numbers after 'TP' means the measurement is between the two test points - with postive clipper on one, negative on the other. Others are between the test point and ground. 

We can see there is a little bit distortion lines in the spectrum under 100Hz, but they are very small compared to the response to the drive. I think maybe they could explain the low frequency bump logged in 1843. However, it seems unlikely that they will be a serious issues in the passband, but still needs a little more rigorous justification.

I calculated the DAC noise for L1. Attachment 1 has all the plots and data. Attachment 2 is the result in strain.

We have noisemon at all four stations: ITMX, ITMY, ETMX, ETMY. DTT gives me the CSD, the coherences and the ASD of all the channels at all the four stations. I use this to calculate the transfer functions of the coil driver and the noisemon.

where D(f) is the drive and CSD is the CSD between the drive and the output of noisemon. The absolute value of H(f) will be the gain of the circuit, in ADC counts / DAC counts. Then I use the coherence to calculate the total noise

This noise has DAC noise, ADC noise, noisemon noise in it. This noise is in DAC counts. I will call this "DriveNoise".

Then I picked another time when the interferomter is not running and the drive is zero. I measured the noisemon spectrum N(f) at that time. The plots and data of these spectrum can be found in attachment 1. The plots are considered to be a result of the noisemon noise and ADC noise, which I will call "NoDriveNoise" (in ADC cts). Since the drive is zero, there is no DAC noise in it - just ADC noise and noisemon noise. I use the transfer function to covert it to DAC counts

Then I subtract the noise drive noise from the drive noise to get the DAC noise to get the DAC noise, which is then converted to DAC volts

Then I find the current on the coil using the transfer functions of the coil driver, assuming the coil driver is in LP OFF and ACQ OFF state. The transfer function can be found in attachment 1.

where the transfer function H is a voltage-to-current transfer function.

Then we have the force

Lastly we have the displacement and strain

For each station I summed all the four channels, LL, LR, UL, UR and then I calculated for all the four stations and summed as

I tried to compare this with the GWINC model - it is much higher. I do not have real L1 noise at the moment. I will see once we have real noise data.

you have to overlay the estimated displacemnt noise with the existing L1 noise bud or else we cant tell what the importance of the result is

There we go. Based on the noisemon data at L1 and H1, I calculated the DAC noises at those sites, using roughly the same approach as described in 1847.

I used the coherence between the master channel and the noisemon channel to calculate the total noise going into the coils.

Then I converted the ADC noise and noisemon noise to DAC volts and subtracted them from the total noise. I compared the result of the subtraction, which should be DAC noise, at least in the passband (20-100Hz), with the G1401399 model and made a noise budget, shown in attachment 1. We can see that, as designed, the DAC noise is sufficiently amplified so that it dominates over the noisemon noise or the ADC noise in the passband.

Next, I projected the DAC noise to strain noise and summed them up for all the four channels in all the four stations.

Finally, I compared this with the interferometer noise spectrum based on data in L1:OAF-CAL_DARM_DQ and H1:CAL-DELTAL_EXTERNAL_DQ. I calibrated these data with calibration files here. The results are shown in attachment 3. All the data and scripts are included in attachment 4, where analysis.py is the script that does the job. Based on the plots, it seems DAC noise could be potentially a limiting factor for the interferomter sensitivity.

The coil driver states for L1 is LP off, ACQ off (state 1). For H1 is LP on, ACQ off. The LISO files calculating the current transfer functions and the voltage transfer functions are attached in attachment 4. 

I used a resolution of 1mHz in the diaggui measurement. The data files are too large so I can not upload them here. I am figuring out what to do.

Note: I fell into a few traps during the calculation. Many of them was about data and transfer functions. I have been more careful about what data is used in these calculations. For example, the noisemon data downloaded from the sites when MASTER was off still has DAC noise in it. I thought it was ADC noise + noisemon noise before and used it for subtraction. Another example, the transfer function measured at the sites has all the noise in it. We do not see the noises in the passband but ADC noise dominates at high frequencies. If you use this transfer function to figure out how much noisemon noise contributes, you result will be tampered by the noises, like ADC noises at high frequency. Last example, if you use the noisemon noise data measured in the digital system in our lab, you should be aware that, although it does not have DAC noise (I disconnected DAC when measuring the noises), it also has ADC noise. Therefore, it would be better to use data from SR785 or LISO simulations (which has been shown to agree with each other). I drew a diagram in attachment 2 to help thinking about what data or transfer functions should be used. 

for some reason the DAC noise estimate is too high, it can't really be so large compared to the real DARM curve (see the noise budget curves from LLO - there are other noise sources besides DAC noise)

some possibilities:

1. maybe the DAC noise calibration into meters is wrong? I can't tell from the code where this came from. It would be good to put a comment in there.
2. perhaps most of this noise is actually angular noise. The ASC control signals are adjusted by tuning the digital coefficients (before MASTER_OUT) so that the angle to length coupling is minimized. I think something like this has to be done to remove the angular noise from the DAC noise estimate.
3. internal saturation of the DAC noise monitor?

I hve modified the code to plot nicer and also to remove some divide by zero problems. There is also still some warnings about other divide by zero - those should probably be fixed by examining how better to handle it when the coherence goes to zero.