Displaying reports 981-1000 of 77255.Go to page Start 46 47 48 49 50 51 52 53 54 End
Reports until 13:26, Thursday 20 June 2024
H1 SQZ (SQZ)
karmeng.kwan@LIGO.ORG - posted 13:26, Thursday 20 June 2024 - last comment - 09:51, Friday 21 June 2024(78556)
SHG-2 escape efficiency

Added a beamsplitter and photodetector at the input of the SHG cavity to measure the escape efficiency.

The reflected beam from the SHG (blue trace) gives an escape efficiency of 98.1%. The theoretical escape efficiency of the SHG is 98.5% for mirror reflectivity of 90% and 99.85%.

The escape efficiency is calculated via Ptrans/Prefl = (2nesc - 1)2. From the reflected beam, the Ptrans/Prefl = 3.19/3.45.

The escape efficiency calculated from the mirror transmissivity is, nesc = Tinput / Ttotal = 0.985

Images attached to this report
Comments related to this report
karmeng.kwan@LIGO.ORG - 09:51, Friday 21 June 2024 (78571)

After tweaking the cavity allignment, I managed to obtain an escape efficiency of 98.6% after taking into account of the higher order mode.

The new Ptrans / Prefl = (3.43 - 0.3) / (3.61 - 0.3) & nesc = 0.986

Images attached to this comment
H1 CAL (CAL, ISC)
francisco.llamas@LIGO.ORG - posted 12:43, Thursday 20 June 2024 (78555)
Drivealign L2L gain changes using kappa_tst

SheilaD, ThomasS, FranciscoL [Remote: LouisD]

We changed H1:SUS-ETMX_L3_DRIVEALIGN_L2L_GAIN by 1.47%. This change improved H1:CAL-CS_TDEP_KAPPA_TST_OUTPUT by 1.26%.

The output from KapppaToDrivealign.py has been saved on 240620_KappaToDrivealign.txtKappaToDrivealign.py calculated the gain change before running calibration measurements, close to 0800 PDT. H1:SUS-ETMX_L3_DRIVEALIGN_L2L_GAIN was changed from 184.65 to 187.379226 (see etmx_l2l_gain_sdf.png for SDF log of the changes) after the calibration measurement was done, around 0830 PDT. A second calibration measurement was executed about 20 minutes after the gain change. 240620_KAPPA_TST-DRIVEALIGN_GAIN_minutes_total.png shows trends of the significant channels through this process.

From 240620_KAPPA_TST-DRIVEALIGN_GAIN_minutes.png the mean of KAPPA_TST (by eye) from the time in between both calibration measurements is of 0.997831. At the time the gain change was calculated and before the first calibration measurement, the mean of KAPPA_TST is of 0.985236. H1:CAL-CS_TDEP_PCAL_LINE3_UNCERTAINTY did not increase to a concerning level. The change of KAPPA_TST is 100*(1 - 0.985236/0.997831) ~ 1.26%.

KappaToDrivealign.py needs debugging (e.g.: not using PCAL_LINE3_UNCERTAINTY data) but it is good enough to calculate (and change) the gain of H1:SUS-ETMX_L3_DRIVEALIGN_L2L_GAIN such that KAPPA_TST improves. We saved the value of H1:SUS-ETMX_L3_DRIVEALIGN_L2L_GAIN on SDF.

Images attached to this report
Non-image files attached to this report
H1 ISC
camilla.compton@LIGO.ORG - posted 12:37, Thursday 20 June 2024 (78554)
aligoNB injections taken

Took Jitter, MICH, PRCL, SRCL LSC, CHARD, DHARD, CSOFT, DSOFT,  MICH ASC noise budget injections. Following instructions in 74681. Last taken by Sheila May 9th.

Had some git issues (whoops, I will remember to pull first next time) but the templates are committed locally in ligo/gitcommon/NoiseBudget/aligoNB/aligoNB/H1/couplings and I will work on pushing to the aligoNB git.

Analysis instructions in 74788. Used DARM time gpstime: 1402575668 # June 16, 2024, 12:20 UTC, Observing Time, O4b, IFO locked 10 hour, 160MPc range. Attached Jitter, Laser noise,  ASC and LSC plots.

Images attached to this report
Non-image files attached to this report
LHO General
thomas.shaffer@LIGO.ORG - posted 12:19, Thursday 20 June 2024 (78557)
Ops Day Mid-Shift Report

Back to Observing at 1905 UTC after commissoining and calibration wrapped up.

Locked for 11 hours.

H1 SQZ
camilla.compton@LIGO.ORG - posted 11:01, Thursday 20 June 2024 (78551)
FC IR OLG Measurement

Sheila, Naoki, Camilla

Ran template: sqz/h1/Templates/dtt/filter_cavity/FC_IR_OLTF.xml Last done in 74228.

If IN2/EXC had peaks > 3 we'd be worried, but everything looks fine. Plot attached.

Images attached to this report
H1 ISC
thomas.shaffer@LIGO.ORG - posted 10:28, Thursday 20 June 2024 (78552)
Ran A2L P

Ran the (userapps)/isc/h1/scripts/a2l/a2l_min_multi.py script for all four quads in P. Changes below have been saved in lscparams.py


         ETMX P
Initial:  3.25
Final:    3.26
Diff:     0.01

         ETMY P
Initial:  4.39
Final:    4.35
Diff:     -0.04

         ITMX P
Initial:  -1.01
Final:    -1.0
Diff:     0.01

         ITMY P
Initial:  -0.35
Final:    -0.38
Diff:     -0.03
 

Images attached to this report
LHO VE
david.barker@LIGO.ORG - posted 10:26, Thursday 20 June 2024 (78553)
Thu CP1 Fill

Thu Jun 20 10:07:20 2024 INFO: Fill completed in 7min 17secs

Gerardo confirmed a good fill curbside.

Images attached to this report
H1 CAL
thomas.shaffer@LIGO.ORG - posted 09:22, Thursday 20 June 2024 (78548)
Calibration Sweep 1500 UTC

Ran two cal measurements this morning on either side of Francisco's ETMX L2L gain changes. Both followed the usual procedure defined in the TakingCalibrationMeasurements wiki. The screenshot was taken before the 1st run 6.5 hour into a lock.

1st Simulines start:

PDT: 2024-06-20 08:06:51.941398 PDT
UTC: 2024-06-20 15:06:51.941398 UTC
GPS: 1402931229.941398
 

1st end:

2024-06-20 15:28:22,642 | INFO | File written out to: /ligo/groups/cal/H1/measurements/DARMOLG_SS/DARMOLG_SS_20240620T15065
2Z.hdf5
2024-06-20 15:28:22,649 | INFO | File written out to: /ligo/groups/cal/H1/measurements/PCALY2DARM_SS/PCALY2DARM_SS_20240620
T150652Z.hdf5
2024-06-20 15:28:22,654 | INFO | File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_L1_SS/SUSETMX_L1_SS_20240620
T150652Z.hdf5
2024-06-20 15:28:22,658 | INFO | File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_L2_SS/SUSETMX_L2_SS_20240620
T150652Z.hdf5
2024-06-20 15:28:22,662 | INFO | File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_L3_SS/SUSETMX_L3_SS_20240620
T150652Z.hdf5
ICE default IO error handler doing an exit(), pid = 973672, errno = 32
PDT: 2024-06-20 08:28:22.713653 PDT
UTC: 2024-06-20 15:28:22.713653 UTC
GPS: 1402932520.713653
 

2nd Simuline start:

PDT: 2024-06-20 08:57:18.632776 PDT
UTC: 2024-06-20 15:57:18.632776 UTC
GPS: 1402934256.632776
 

2nd end:

2024-06-20 16:18:49,410 | INFO | File written out to: /ligo/groups/cal/H1/measurements/DARMOLG_SS/DARMOLG_SS_20240620T15571
9Z.hdf5
2024-06-20 16:18:49,423 | INFO | File written out to: /ligo/groups/cal/H1/measurements/PCALY2DARM_SS/PCALY2DARM_SS_20240620
T155719Z.hdf5
2024-06-20 16:18:49,430 | INFO | File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_L1_SS/SUSETMX_L1_SS_20240620
T155719Z.hdf5
2024-06-20 16:18:49,436 | INFO | File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_L2_SS/SUSETMX_L2_SS_20240620
T155719Z.hdf5
2024-06-20 16:18:49,440 | INFO | File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_L3_SS/SUSETMX_L3_SS_20240620
T155719Z.hdf5
ICE default IO error handler doing an exit(), pid = 1075203, errno = 32
PDT: 2024-06-20 09:18:49.496542 PDT
UTC: 2024-06-20 16:18:49.496542 UTC
GPS: 1402935547.496542
 

Images attached to this report
H1 SEI
anthony.sanchez@LIGO.ORG - posted 09:14, Thursday 20 June 2024 (78550)
H1 ISI CPS Noise Spectra Check - Weekly

FAMIS - 25996 H1 ISI CPS Noise Spectra Check - Weekly

Todays's CPS spectra does not look much different than the previous noise spectra taken alog 78352.

 

 

Non-image files attached to this report
H1 SQZ (DetChar, DetChar-Request)
camilla.compton@LIGO.ORG - posted 09:04, Thursday 20 June 2024 - last comment - 10:34, Wednesday 26 June 2024(78549)
SQZ Laser is Glitchy since May 20th, CLF ISS gltihcy since O4b start.

Vicky, Begum, Camilla: Vicky and Begum noted that the CLF ISS and SQZ laser is glitchy.

Vicky's plot shows CLF ISS glitches started with O4b, attached.

Timeline below shows SQZ laser glitches started May 20th and aren't related to TTFSS swaps. DetChar - Request : Do you see these gltiches in DARM since May 20th?

  • Pre-April 25: no glitches
  • 25 April:  TTFSS issues, Removed Chassis S2300258, Installed Chassis S2300259 (alog 77418); also caused SQZ rack glitch: 77424 / FRS 31061
  • 25 April - 7 May: no glitches apart from on Tuesday April 30th
  • 7 May: Reinstalled repaired TTFSS. Removed Chassis S2300259, Installed Chassis S2300258 (77688)
  • 7 May - May 20th: Glitches stay small
  • May 20th 22:00UTC (Monday): First glitch shown on detchar summary page /20240520/sqz/glitches/
    • Day shift summary: 77941 included PR2 spot move, but don't expect glitches could be  IFO alignment dependent.
  • Lots of glitches since May 20th.  These glitches aren't constant and seem to get better and worse on different days, in general got worse since May 20th.

Summary pages screenshots from: before glitches started, first glitch May 20th (see top left plot 22:00UTC), bad glitches since then.

Images attached to this report
Comments related to this report
camilla.compton@LIGO.ORG - 12:25, Monday 24 June 2024 (78626)

Missed point:

  • 9 May: TTFSS issues, Removed Chassis S2300258, Installed Chassis S2300259, 77734  later saw the issues were from fiber polarization not the chassis.
andrei.danilin@LIGO.ORG - 14:08, Monday 24 June 2024 (78627)

In addition to previous report, I must note that glitches started on May 9th and continued for several times even before to May 25th.
Glitches are usually accompanied by the increased noise in H1:SQZ-FIBR_EOMRMS_OUT_DQ and H1:SQZ-FIBR_MIXER_OUT_DQ channels.

Images attached to this comment
andrei.danilin@LIGO.ORG - 10:34, Wednesday 26 June 2024 (78673)

Andrei, Camilla

Camilla swapped the TTFSS fiber box 78641 on June 25th in hopes that this will resolve the glitches issue.

However, it made no difference: Figure (see from 20:40 UTC, as it is when TTFSS box was swapped).

Images attached to this comment
LHO FMCS
tyler.guidry@LIGO.ORG - posted 08:18, Thursday 20 June 2024 (78547)
Chiller Rotation at End X
In preparation for a leak investigation and repair, the chillers at EX have been rotated. We are monitoring the rotation closely. As such, no interruption to HVAC or desired temps is expected. At this time, chiller 2 seems to working as expected. The current configuration of lead/lag will remain until the next ~quarterly cycle. 

E. Otterman T. Guidry
LHO General
thomas.shaffer@LIGO.ORG - posted 07:33, Thursday 20 June 2024 (78545)
Ops Day Shift Start

TITLE: 06/20 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 149Mpc
OUTGOING OPERATOR: Tony
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 20mph Gusts, 11mph 5min avg
    Primary useism: 0.05 μm/s
    Secondary useism: 0.05 μm/s
QUICK SUMMARY: Locked for 6 hours, range seems to be stable around 154Mpc (cleaned). Planned calibration and commissioning today from 8-12 PT (15-19UTC)

H1 General
ryan.crouch@LIGO.ORG - posted 01:00, Thursday 20 June 2024 (78544)
OPS Wednesday EVE shift summary

TITLE: 06/20 Eve Shift: 2300-0800 UTC (1600-0100 PST), all times posted in UTC
STATE of H1: Lock Acquisition
INCOMING OPERATOR: Tony
SHIFT SUMMARY: 1 lockloss, currently relocking after running an IA
LOG:

Lockloss at 06:38 UTC ending a almost 13 hour lock, I had to do an IA to relock due to bad DRMI & PRMI flashes, fully automated. We're about to power up to 10W as of the end of my shift.

H1 General (Lockloss)
ryan.crouch@LIGO.ORG - posted 23:40, Wednesday 19 June 2024 (78543)
Lockloss at 06:38 UTC

Lockloss at 06:38 UTC

H1 General
ryan.crouch@LIGO.ORG - posted 21:06, Wednesday 19 June 2024 (78542)
OPS Wednesday EVE shift update

We've been locked for just over 10 hours, all is calm on site. High frequency squeezing isn't quite as good as it was earlier in the week.

LHO General
thomas.shaffer@LIGO.ORG - posted 16:26, Wednesday 19 June 2024 (78540)
Ops Day Shift End

TITLE: 06/19 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 148Mpc
INCOMING OPERATOR: Ryan C
SHIFT SUMMARY: One lockloss with an automated relock. Our range was around 150, but has since increased a handful of Mpcs now. It looks like CHARDY and DHARD_Y are looking a bit better.
LOG:

Images attached to this report
H1 General
ryan.crouch@LIGO.ORG - posted 15:59, Wednesday 19 June 2024 - last comment - 16:15, Wednesday 19 June 2024(78539)
OPS Wednesday eve shift start

TITLE: 06/19 Eve Shift: 2300-0800 UTC (1600-0100 PST), all times posted in UTC
STATE of H1: Observing at 148Mpc
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 14mph Gusts, 10mph 5min avg
    Primary useism: 0.04 μm/s
    Secondary useism: 0.06 μm/s
QUICK SUMMARY:

Comments related to this report
ryan.crouch@LIGO.ORG - 16:15, Wednesday 19 June 2024 (78541)SQZ
SQZ_OPO_LR GRD is notifying: 'pump fiber rej power in ham7 high, nominal 35e-3, align fiber pol on sqzt0.'

Its currently just under 0.36, (0.3 is considered high).

Images attached to this comment
H1 General
thomas.shaffer@LIGO.ORG - posted 10:05, Wednesday 19 June 2024 - last comment - 10:49, Wednesday 19 June 2024(78536)
Lock loss 1617UTC

1402849079

Ended a 20 hour lock. Looking at the plots it seemed to be a very fast lock loss. I see that LSC-DARM wiggle that we often see, but the magnitude of it is a bit smaller than what I have been looking at in the recent past.

Images attached to this report
Comments related to this report
thomas.shaffer@LIGO.ORG - 10:49, Wednesday 19 June 2024 (78538)

Back to observing at 1748 UTC. Fully auto relock with an initial alignment.

H1 ISC (CAL, CDS)
jeffrey.kissel@LIGO.ORG - posted 12:37, Tuesday 18 June 2024 - last comment - 15:57, Thursday 20 June 2024(78516)
Investigating the High Frequeny Performance of the OMC DCPD Anti-aliasing System
J. Kissel

I'm on a slow-but-steady adventure to characterize the performance of the digital anti-aliasing system for the new 524 kHz ADC readout of the OMC DCPDs photocurrent. 
The big picture goal is too look at the 524 kHz data, and make sure that it's filtered enough before down sampling to 65 kHz and then 16 kHz, such that none of "fun and interesting" features that are real DARM signals (or analog or digital artifacts of the ADC) in the 10 - 100 kHz region appear down-converted at low frequency.

As usual, when I *look* at something for the first time, hoping for a simple "yup, works as expected," I instead get 60 new questions.

Executive summary: 
While I don't see anything obviously detrimental to the 16 kHz data, I see a confusing, frequency-independent noise floor in the filtered version of the 524 kHz OMC DCPD A channel *only* in NOMINAL LOW NOISE that I can't explain as either ADC noise, spectral leakage, or limits of numerical precision. Apparently, in NOMINAL LOW NOISE, we're not getting nearly as much digital anti-aliasing as designed.

Plots and their Explanation, Exploration, and Conclusions:

First, I compare the amplitude spectral densities of the two 524 kHz channels available for DCPD A during NOMINAL LOW NOISE vs. when DARK (the IMC OFFLINE), "as the are" 
    - H1:OMC-DCPD_A0_OUT (calibrated into milliamps [mA] on the DCPDs),                        # HAS 526-to-65 kHz and 65-to-16 kHz digital AA filters
    - H1:OMC-PI_DOWNCONV_SIG_OUT (a copy of the DCPD A channel, also calibrated into [mA]),    # DOES NOT HAVE digital AA filters

The first attachment, H1OMCDCPDs_0p1HzBW_10avgs_524kHzSignals_NLN_vs_DARK_AprtHz.png shows this comparison. 
These are the *output* of the respective filter banks, so the front-end filter banks already do *most* the work of inverting the frequency response of the TIA and Whitening filters, below 10 kHz.
That front-end calibration also already accounts for the fact that the analog voltage coming into the ADC is copied 4 times and summed, and does the "divide by four" gain of 0.25 to create an average of the voltage copies.
Importantly, the TIA and whitening's analog 11130 & 10170 and 44818.4 Hz poles are *not* inverted, so they remain a part of the frequency response of the readout -- and thus they remain uncompensated for in the plot.
The *only* calibration applied in DTT for these channels is a simple 1e-3 [A/mA].
    NOMINAL LOW NOISE, "reference" data for the two channels -- shown in CYAN and MAGENTA -- was taken a last week on 2024-06-12 20:45:46 UTC.
    DARK noise, "live" data for the two channels -- shown in RED and BLUE -- was taken this morning, with the IMC offline at 2024-06-18 15:10:28 UTC.

One immediately notices several "interesting" things:
    (1) The CYAN, OMC-PI_DOWNCONV_SIG_OUT version of the (4x copy average of the) DCPD A signal -- that doesn't have digital anti-aliasing filters applied -- shows lots of "fun and interesting" features on the DCPDs above 8 kHz in NOMINAL LOW NOISE. 
    (2) Comparing the CYAN NOMINAL LOW NOISE data with BLUE DARK data, we see that a lot of these "fun and interesting" features in the 8 kHz to 100 kHz region are real features from the detector. My guess is that this is the forest of acoustic modes of optics that appear in the DARM signal.
    (3) MAGENTA OMC-DCPD_A0_OUT version shows that most of these features *are* filtered out by 30 kHz by the digital AA filtering, BUT -- they hit some frequency-independent noise floor at "1e-12 [A/rtHz]."  This noise floor is obviously *not* a real noise floor on the DARM light coming in on the PDs, nor some sort of current noise, given how feature full the CYAN unfiltered version is. As such I will for the remainder of the aLOG put the quantitative numbers about this noise floor in quotes. What is this noise floor?
    (4) Comparing MAGENTA NLN trace and RED DARK trace, we see that when the DCPD is DARK, we see the full expected frequency response of the digital AA filters. Why are the filtered data's DARK and NLN noise floors so different?

Hoping to understand this noise floor better, I calibrated the traces into different units -- the units of input voltage in to the low-noise, 18 bit, 524 kHz ADC.
The second attachment, H1OMCDCPDs_0p1HzBW_10avgs_524kHzSignals_NLN_vs_DARK_CastAsADCInput_VprtHz.png, shows this different version of the ASD.

To calibrate into ADC input voltage units, I calibrated all the DTT traces by the following calibration (with detailed poles and zeros pulled from the calibration group's DARM loop model parameter file, pydarm_H1.ini from the 20240601T183705Z report): 
    zpk([2.613;2.195;6.556],[5.766+i*22.222;5.766-i*22.222;32.77;11130;10170],219.65,"n") # The TIA response [V/A], normalized to have a gain of 100e3 [V/A] at 1 kHz
  * zpk([0.996556],[9.90213;44818.4],1,"n")                                               # The Whitening Response [V/V]
  * gain(0.001)                                                                           # The inverse of the [mA]
where notably, I continue to exclude the two 11130, 10170 Hz poles and the 44818 Hz pole from the TIA and whitening filter's analog response. 

To compare against our model of the noise of the low-noise, 18-bit ADC sampled at 524 kHz (derived from the data in LHO:61913, shown to be comparable in G2201909), I took that model and divided by sqrt(4) = 2.0 to account for the 4 copies of the ADC noise that appear during the digitization of the 4 copies of the analog voltage. 

I also show the RMS voltage (color coded to match the corresponding ASD) in case that's important for discussions of noise floors.

This exposes more interesting things, and rules out one thing that this 1e-12 [A/rtHz] noise floor might be -- it's *not* the ADC noise floor.
    (5) Both version of the DARK noise traces, BLUE and RED show that the data agree with the noise model below 5 Hz, which gives me confidence that the scale of the model is correct across all frequencies.
    (6) The MAGENTA trace shows that, when recast into ADC input voltage, the filtered nominal low noise data's "1e-12 [A/rtHz]" noise floor is "1e-6 [V/rtHz]," which is a factor of ~4 above modeled ADC noise floor.
    (7) The BLUE trace shows the dark noise -- without the digital anti-aliasing filters -- is *also* above the ADC noise, is frequency-dependent, and *below* the MAGENTA filtered NOMINAL LOW NOISE data in the 20 to 200 kHz region. 
(5), (6), and (7) all give me confidence that this frequency independent noise is *not* ADC noise
    (8) The ADC input voltage 
        (a) during NOMINAL LOW NOISE data spans 5 orders of magnitude (0.2 [V_RMS] total in the CYAN NLN unfiltered trace, w.r.t. this 1e-6 [V/rtHz] high frequency noise floor in the filtered MAGENTA trace), and
        (b) the DARK data spans 6 orders of magnitude (5.4e-4 [V_RMS] of the BLUE unfiltered trace, w.r.t the 1e-10 [V/rtHz] at the lowest 65 kHz notch in the RED trace). But BOTH are still above the dynamic range of where floating point precision would be causing problems -- dynamic range of 8 orders of magnitude. So, I don't think it's a numerical precision issue, unless I'm misunderstanding how that works.
    (9) Also, given that the NOMINAL LOW NOISE data spans less orders of magnitude that the DARK noise data, and yet the filtered RED data does *not* show any such frequency-independent noise floor, I also don't think it's an issue what window I've chosen on the ASDs (it's the default Hanning window, for the record).

Just to add another view in further different units, to explore (8) a little better, I attach a third version of the plot, but cast into the 18 bit ADC's counts.
This is the third attachment, H1OMCDCPDs_0p1HzBW_10avgs_524kHzSignals_NLN_vs_DARK_CastAsADCInput_ctprtHz.png.
The further calibration is a simple multiplication of the ADC Input Voltage by a further 2^18/40 [ct/V]. 
(The inverse of this ADC voltage calibration has already been done in the "raw" channels in [mA], and the factor of 4 for the number of copies being summed has already been accounted, so I *can* treat these channels like a single ADC channel).
    (10) Not much more interesting here, the MAGENTA trace showing "1e-12 [A/rtHz]" or "1e-6 [V/rtHz]" high frequency noise floor of the filtered NOMINAL LOW NOISE data, now in ADC counts, lands at an uninteresting "7e-3 [ct/rtHz]", compared to an RMS of ~1000 [ct_RMS]. So, it's not like we're bottoming out on ADC counts or ADC precision.

I'd really like to understand this noise, since it's present during NOMINAL LOW NOISE, and it's indicating that there's some flaw in our digital anti aliasing.
Images attached to this report
Comments related to this report
jeffrey.kissel@LIGO.ORG - 12:40, Tuesday 18 June 2024 (78521)
In case folks are interested, I attach a few zooms of the > 10 kHz region.

The first two attachments are in "raw" DCPD current units [A/rtHz], and the third attachment is in ADC input voltage units [V/rtHz] so one can compare against the ADC noise floor model.
Images attached to this comment
jeffrey.kissel@LIGO.ORG - 13:00, Tuesday 18 June 2024 (78522)
The calibration in DTT was not so easy. 

For the DCPD channels, I ended up creating the appropriate calibration filter in foton, then exporting the trace to text file, then by-hand copying-and-pasting that text file's results into the funtional table in "Trans. Func." tab. I used this method and foton because I can
   - have separate filters for each TIA, Whitening, mA to A, ADC gain, components
   - bode plot the answer so I can sanity check the frequency response, and confirm the overall scale factors is correct (in particular, that the TIA had magnitude of 100e3 [V/A] at 100 kHz)
rather than the DTT "Pole/Zero" tab, where
   - the calibration filter is all in one long collection of poles and zeros, 
   - I have no idea how the poles and zeros are normalized, and 
   - I can't visually check the filter response and magnitude.

I attach a screenshot of the foton design that shows all the filters needed above,
   - the TIA
   - the Whitening
   - the mA per A gain
   - the ADC ct per V gain 
and the "Command" field shows all of these filters' details multiplied together (separated by the asterisk).

I used the filter file 
    /opt/rtcds/lho/h1/chans/
        H1IOPOMC0.txt
from the h1iopomc0 front-end model because it's a 524 kHz filter file, allowing me to add frequency response features above the traditional 8 kHz Nyquist frequency of a 16 kHz model (even though I didn't end up adding any of those features, I had thought for a while that I would have, given that the TIA and Whitening have the above mentioned ~11, 10, and 44 kHz poles. But, as discussed above, I don't need them.)
Note, I didn't save this filter or load it into the front-end or anything, I just used the filter bank as a sandbox to create the calibration filters.

For the ADC noise, I took the noise model from the svn directory for the OMC whitening design update,
     /ligo/svncommon/CalSVN/aligocalibration/trunk/Common/Documents/G2201909/
         BHD_PreampOnlyAndAdcNoise_10mA_6dBSqueeze_512kHzSample_adc.txt
which is already in ADC input voltage [V/rtHz] units, then imported it into matlab, divided by 2 and re-exported for the average-of-four-channels ADC noise curve in the main aLOG's second attachment.
Then, I multiplied this average-of-four-channels noise estimate by the 2^18/40 [ct/V] and re-exported for the ADC noise curve in the main aLOGG's third attachment.

The DTT templates for this work live in 
    /ligo/home/jeffrey.kissel/2024-06-12/
        2024-06-18_151028UTC_H1OMCDCPDs_DARK_0p1BW_10avgs.xml                      # calibrated into raw DCPD current in [A/rtHz]
        2024-06-18_151028UTC_H1OMCDCPDs_DARK_0p1BW_10avgs_calibratedtoADCV.xml     # calibrated into ADC input voltage in [V/rtHz]
        2024-06-18_151028UTC_H1OMCDCPDs_DARK_0p1BW_10avgs_calibratedtoADCct.xml    # calibrated into ADC counts in [ct/rtHz]


I attach the calibration files and ADC noise curves produced for this aLOG as well (which are also in that 2024-06-12 directory in my home folder).
Images attached to this comment
Non-image files attached to this comment
jeffrey.kissel@LIGO.ORG - 15:57, Thursday 20 June 2024 (78559)
J. Betzwieser, E. von Reis, J. Kissel
T990013 DTT Manual, Section 3.1.4

It *is* a numerical precision issue -- I *didn't* understand understand "how it worked" er, what I was missing.

Long story short --- the above DTT ASDs have the "Remove Mean" option checked as ON. 
The data actually contains a comparatively *huge* DC component -- the well known 20-ish [mA_peak] of light that comes in from the DARM offset. 
The front end data is spit out to test points at single precision.
Compared with the ~1e-12 [A_rms/rtHz] or less signal I'm trying to explore, that *is* a huge dynamic range that does push the numerical limits of the single-precision test point data.

Here, I attach the same ASD comparison between the "raw" 524 kHz ADC channel (the OMC-PI_DOWNCONV channel) and the output of the OMC-DCPD_A0 bank after the digital down sampling filters. 
First attachment is the full frequency vector, and the second attachment is the high-frequency portion.
For all traces, the detector is in NOMINAL LOW NOISE, and for this purpose I found it more natural to use the signals calibrated into ADC input voltage units. However, in the attached, I now compare the two channels under three different configurations of the DTT analysis software:
    (1) The same CYAN and MAGENTA, nominal low noise data as in the main entry taken on 2024-06-12. This still has the "Remove Mean" option checked, *and* is using the control room's default diaggui software suite, which computed the pwelch algorithm using single-precision.
    (2) I took new data today 2024-06-20, also in nominal low noise, but this GREEN and BROWN data set is using Erik's more feature-full developmental
        /usr/bin/diaggui_test
       which computes the pwelch algorithm using double precision, and
    (3) One more data set, taken shortly after (2), in BLUERED, which uses the double-precision calculation, but I've *unchecked* the "Remove Mean" option, and thus exposed the DC component of the signal.

Trending a typical NLN segment, the first "officially named" available channel in the digital chain of the DCPD readout is the sum of the 4 copies of the analog voltage. 
That's H1:OMC-DCPD_A0_IN1 (or the 16 Hz readback version H1:OMC-DCPD_A0_INMON), and that reads 
    116700 [ct] * (40/2^18 [V/ct]) = 17.8 [V_DC] * (1 / 4 [copies]) = 4.45 [V_DC].
The unofficial generic CDS channels for each ADC channel are also available (H1:IOP-OMC_MADC0_EPICS_CH[0,4,8,12]), that these signals, before the sum, also corroborate 4.5 [V_DC], 
    29200 [ct] * (40/2^18 [V/ct]) = 4.45 [V_DC]
So that's the upper end of the dynamic range of the signal we're dealing with, in ADC input voltage units.

Here's what we see in the attachments:
    (i) When we uncheck the "Remove Mean" box, the secrets are revealed -- the lowest frequency data point reports ~4 [V_DC]
    (ii) -- and echo of (b), given the dynamic range of this signal, computing pwelch algoirthm in single precision or double precision results in the same noise floor of "1e-6 [V/rtHz]" above ~10 kHz where the real noise is small.

But -- it isn't 8 orders of magnitude smaller... so I also wonder if we hit this noise because of the order in which we compute the filters within the A0 bank. For the purposes of discussion, I attach 
    - the total transfer function of the A0 bank, H1OMCDCPD_A0_FilterBank_TF.png
    - each of the filters in the bank, in order, H1OMCDCPD_A0_FilterBank_Component_TF.png
    - the MEDM screen, for ease of interpretation H1OMCDCPD_A0_FilterBank_MEDM.png

The front-end computes everything in double precision, right?
Images attached to this comment
Displaying reports 981-1000 of 77255.Go to page Start 46 47 48 49 50 51 52 53 54 End