It seems to have started on Friday after the last shift before the SDB1/PR intervention and present during that weekend lock.
This noise is still present in the first locks of today (figure 2).
Figure 3, shows that the excess noise started somewhere between 18:00 and 23:00 UTC. Could it be related to the suspension and alignment work mentioned in the operator logbook entry? Some noise injection in a marionetta could easily explain a 1/f^4 noise.
On October 6th I worked on suspension IP controls. The activity is going on since the end of the run and is supposed to have no impact on the sensitivity in good weather conditions. The goal is an improvement of lock robustness and alignment stability during bad weather conditions.
In addition, a different filter for the control of DIFFp_TX was tested, and then the previous filter was put back.
During those activities some DSP code was updated and some mistake could have been done, but I didn't find anything evident. All the correction sent to the marionette actuators looks the same as before. The investigation will go on.
Trying to understand the noise budget at high frequency, we noticed that NE optical gain suddenly dropped on the evening of October 6. This drop of about 25% (like one coil out of 4...) is not visible on WE or BS, indicating a change specific to the NE mirror. This is exact moment when the 1/f^4 noise started.
As a side effect, the overall calibration might be wrong by half of this value, i.e. about 12%, since October 6. In first approximation is probably like the inspiral range is underestimate by this amount since this time (to be checked).
After a quick look at the calibration data that we did not analysed regularly, it seems that something changed on NE actuation.
The following table gives the actuation gain at 10 Hz, at three different dates, for NI and WI in HP mode and for NE and WE in LN2 mode, in µm/V (gain normalized to a pendulum model). The quality of all the calibration data have not been checked yet. I think we do not have calibraiton data between Sept 19th and Oct 24th.
| NI | NE | WI | WE | |
| 02 | 0.46 | 0.48 | 0.45 | 0.44 |
| 19/09/2017 | 0.46 | 0.46 | 0.45 | 0.42 |
| 24/10/2017 | 0.46 | 0.35 | 0.45 | 0.43 |
--> one can see that the response of NE actuation seems to have decreased by ~25% sometime in between the two measurements, while the other are stable. The overall shape of the NE actuation response does not seem to have changed, except for the gain.
Can one of the four NE coils be desactivated?
indeed...
It is like that since Oct 6 at 22 local time. At that time an offset of 0.5 volts has been written in the NECDMir DSP and sent to the DAC (fig 1). The value is amplified and goes above the saturation when locking mode pass to low noise 2.
The only candidate to be the responsible of the mistake is me, but eventually I did not do it on purpose, because it is not a place where I use to write.
It is interesting to notice that just a line below there is a GNAME which can assume the value of 0.5, and is written by the automation sometimes during the lock acquisition. To be noticed also that the 0.5 in the bad place has been written a couple of seconds after an unlock, when usually the automation sends cm commands to set the initial parameters for the lock acquisition. It would be worth to investigate if it is possible that a cm command has been received by the DSP in a wrong line.
First of all, note that the board you are talking about is NECDMirLN, and the Gname is P1P2_ENBL.
From the log file /virgoLog/Sa/Tango/SatServer_ALL_2017-10-03-06h22m54-UTC.log
...
2017-10-06-20h37m17-UTC INFO SAT_NE_P1P2_ENBL = 0.5 (ramp: 5.0s)
...
The only possibility of a "machine" error is that somebody compiled the DSP code without sending it in execution into the DSP. When a compilation is peformed, all the previous files are overwritten, and there is no way to read the old versions of the configuration files even if they are currently executed by a DSP. Currently, the Tango layer looks for the address that corresponds to a given GNAME reading the file currently in the filesystem, into the .loc file of the corresponding DSP code (the loc file kees the associations between variables and memory address). Differently from Damping, no check is performed if the version of the file correspond to the one running into the DSP. If you add a line into that code without downloading it, then the supervisor changed a gain just next to it.
Looking first at Hrec (Figure 1): in addition to the removal of the 1/f^4 noise, the high frequency (>1kHz) noise is back to what it was on Sept 27 (30.5Mpc). In the middle region 60-300Hz there is still some excess noise, that looking at Hrec seems a bit decreased, but not removed(Figure 2).
Looking at DARM confirms more or less these results but not completely: the 1/f^4 disappeared and the high frequency part reduced essentially to the level it was on Sept 27 (see Figure 2), the excess noise in the middle region 60-300Hz seems has not decreased at all (Figure 4). This discrepancy between Hrec and DARM can be attributed to calibration ?
Figures 5 and 6 show spectral ratios with respect to the reference date of Sept 27. Figure 5 is for Hrec and Figure 6 is for DARM.
Figure 1, there is larger coherence between MICH and DARM, this is reduced between MICH and hrec but not for structures around 150Hz.
Figure 2, looking at the projection of MICH noise in the noise budget, the projection is about a factor 10 below the real coupling. This would mean the coupling between MICH and DARM has changed compared to last week, and the alpha subtraction is not working well at the moment.
This doesn't explain the broadband increase between 60-300Hz that Irene shows, just some structures.
This is probably due to the fact that the last Alpha tuning was done in the bad configuration we've been having in the last weeks; another tuning will be done as soon as possible.
However, it is quite hard to create a flat noise in the interferometer. The usual source of flat noise is excess gas in the tubes, or any other excess differential phase noise. At the level of the beam splitter it corresponds to a optical path fluctuation of ~9e-18 m/rtHz. A noisy TCS laser shining on the compensation plate maybe could produce a flat noise, but I don't think it is hitting the CPs yet. A 1/f noise in the photodiodes could create a similar too, but it would need to be coherent between the two photodiodes, so it is not present in the subtraction of B1_PD1 and B1_PD2, which doesn't make any sense.
Just as a clarification. CO2 laser would produce a 1/f noise, not a flat one.