Adding a TIME plot showing B1_PD1_DC, B1_PD2_DC, B1_PD1_Audio, B1_PD2_Audio, B1_DC_NULL and LSC_DARM.
The glitch covers a frequency band up to 300 Hz and has a large low frequency component.

Figure 1. The glitch is the same in the Audio and DC channels, but it is different in the blended channel. Looking at the transfer function between the blended channels, it is probable it has the same shape as L/(1-L) or something similar, where L is the DARM loop open transfer function. This would mean that the glitch appears in the blending computation in one of the two photodiodes.

The blending filter design looks quite different compared to the old photodiodes, with a pole at 0.006Hz for a channel sampled at 20kHz, the large ratio between the two frequencies could be an issue causing numerical problems.

The B1_PD{1,2}_Blended_simple channel is the sum of the B1_PD{1,2}_Audio_blend with the B1_PD{1,2}_DC_blend channels:

• the  B1_PD{1,2}_DC_blend is computed using the "double_II" method 
• the B1_PD{1,2}_DC_Audio is computed using the  "double_II_lownoise" method due to the pole at 6.092mHz and the input sampling frequency at 20KHz 
  • the ration 20KHz/0.006: 3 333 333, 33 is greater than the ACL_FILTER_DEFAULT_THRES_FSFP set to 500000 . 
  • the first trial is to have the same computing method, "double_II_lownoise",  for the DC_blend and the Audio_blend channels .

This can be done by adding the following lines for the B1_PD{1,2} photodiodes:

• ACL_FILTER_CH_OPTION {PD_DC}_Audio_blend -1 "sin_inout" "linear" 0 10 0 50 # "double_II_lownoise"

• ACL_FILTER_CH_OPTION {PD_DC}_DC_blend -1 "sin_inout" "linear" 0 10 0 50 # "double_II_lownoise"

To apply the fix the following lines need to be uncommented in the SDB2_Photodiode configuration file and the server restarted 

• B1_PD1: lines 140,142 ,
• B1_PD2: lines 181,183,

Figure 1. These glitches can be clearly found in Omicron when B1_DC_NULL is analyzed. I think it corresponds to the red dots between 80Hz and 400Hz.

Figure 2. Looking a month ago this type of glitches was probably already present. We noticed them now as we have been looking more closely at the B1_DC_NULL channel following the issues with B1 PD2.

Note that the 25min glitches are visible in B1 DC NULL now, and were not previously. This is just the consequence of the difference between B1 PD1 and B1 PD2 not being as well fine tuned now, as it was before the B1 photodiode replacement. So now the SNR of the 25min glitches in B1 DC NULL is probably attenuated by factor ~100 instead of ~1000 previously.

The SDB2_B1_DC_NULL_30_300_RMS channel is a useful trigger for this king of event .  At the begining of the 2025-10-15-13h LN3 lock segment there was several events with high SDB2_B1_DC_NULL_30_300_RMS values .

The one reported refer to the  2025-10-15-14h11m events (red rectangle) . 

As trial, the SDB2_B1_PD{1,2}_{Audio,DC} channels were reprocessed  to compute   SDB2_B1_PD{1,2}_Blended channels (plot and it zoom) :

• data segment of  600s between 2025-10-15-14h03m02-UTC GPS144457200  and  2025-20-15-14h13m02-UTC GPS144457800
• the raw  channels are  with the _ref suffix , the reprocessed ones  without 
• There is no glitch on the reprocessed channels
  • this excludes an issue due to different filter computing method use to build the DC and Audio channels 
  • But it suggests a possible sample discrepancy between the B1_PD1 and B1_PD2 channels (Audio,DC) that are provided by 2 different photodiodes mezzanines
    • as a trial  on the SDB2_rtpc, the Tpro cycle could be delayed by a few us (5 us) to wait for the full data availability

As trial to reduce the B1_PD{1,2} glitches , 

• At the SDB2_Photodiode server level, the filter computing method for the B1_PD{1,2}_{Audio,DC}_blend channels has been set to   "double_II_lownoise"
• the SDB2_Tpro LOOP_DELAY has been increased from 20us to 25us to ensure that all the expected Tolm packets are well delivered 
  • most of the SDB2_rtpc servers have been restarted, except the SDB2_dbox_bench server
• at the SDB2_dbox_bench server, a trial has been done to transmit the SDB2_MezzPD1_1 Tolm packet at 20KHz as the   SDB2_MezzPD1_0 one, but without success as it trigs some missing samples for some channels  at the rtpc1's servers (SDB2_LC and SQZ_CTRL)

The Monitoring server  called ServersMoni ahs been updated accordly

Operations completed at  2025-10-16 17h15m19 UTC

This morning, 2025-10-17, at 10H00-UTC there was a glitch in the BNS range . 

Performing the replay with 600s of data, without the logic related to the photodiode saturation,  with the B1_PD{1,2} channels it appeared that the glicthes were not present in the reprocessed channels  , even after the yesterday's tunings .

Looking in more details in the SDB2_Photodiodes Acl's code and in the SDB2_dbox_bench configuration, it appears that:

• at the DBOX level, the B1_PD{1,2}_{Audio,DC} channels are acquired at 100KHz with the suffix _raw but not stored in the DAQ 
• at the Acl level, the  B1_PD{1,2}_{Audio,DC} channels at 20KHz are computed, filtered and decimated and stored in the DAQ .
  • As consequence when the reprocessing is performed using B1_PD{1,2}_{Audio,DC}, its s done with the channels built by the SDB2_Photodiode . This exclude any possible issue with data delivered too late at the rtpc level .
• After further investigations, it appeared that the issue with the B1_DC_NULL_30_300_RMS are mainly due to  the "saturation" protection  of B1_PD{1,2}  channels (see this plot, zoom1 and zoom2 ) 
  • the saturation thresholds need to be adjusted

The audio saturation threshold has been updated from 0.055 to 0.075 mW for the B1_PD1 and B1_PD2 photodiodes. The action was performed at 13h14m32 UTC.

Moreover we have updated the PD flag in the DMS to include a check of the saturation of the audio channels. DetMoni was restarted at 13h40m07 utc.