Jeff, Oli
On Thursday (86507) I alogged the differences we were seeing in the ASC with the SR3 estimator on. The time that I was taking as our 'reference time' for the estimator off, however, doesn't seem like it was a good time showing the lowest the ASC noise could be. You could say this caused us to over estimat(or) the differences.
So I plotted some more times with the estimator off, then with the estimator on, and I found that maybe the SR3 noise is limiting the ASC noise less than shown in 86507. However, I also found that below 0.2 Hz, where we thought that the estimators were elevating the noise, that also seems to have been not related to the estimator, so that is something we might not have to worry about.
Of course the peaks at 0.6 and 0.7 Hz are elevated in the estimator plots below due to not damping them in the inital blend filter (mentioned in 86507), and this is something that we partially fixed this morning (86544), and will be working on further damping at the next available commissioning time.
There are still times where the estimator on makes the noise better at some frequencies, but there are also other times where the estimator is on, but something else is limiting the noise, so it looks like SR3 isn't limiting the noise very much at all. It will still be interesting to see if adding estimators onto the rest of the SRC give us different results.
In the plots below, I am showing the variation in noise with the estimators off and the estimators on,
The 'bad' time for the estimators OFF is: 2025-08-17 09:00 UTC (green)
The 'good' time for the estimators OFF is: 2025-08-20 18:29 UTC (blue)
For the estimators ON times, they're both 'good' and 'bad' at different frequencies, so I'll just list their times:
2025-08-21 16:35 UTC (red)
2025-08-24 18:18 UTC (gold)
| Pitch | Yaw | |||||
| ASC-DHARD | Error | |||||
| Est OFF | Est ON | Both | Est OFF | Est ON | Both | |
| Control | ||||||
| Est OFF | Est ON | Both | Est OFF | Est ON | Both | |
| ASC-MICH | Error | |||||
| Est OFF | Est ON | Both | Est OFF | Est ON | Both | |
| Control | ||||||
| Est OFF | Est ON | Both | Est OFF | Est ON | Both | |
| ASC-SRC1 | Error | |||||
| Est OFF | Est ON | Both | Est OFF | Est ON | Both | |
| Control | ||||||
| Est OFF | Est ON | Both | Est OFF | Est ON | Both | |
| ASC-SRC2 | Error | |||||
| Est OFF | Est ON | Both | Est OFF | Est ON | Both | |
| Control | ||||||
| Est OFF | Est ON | Both | Est OFF | Est ON | Both | |
| ASC-AS_A_DC | Control | |||||
| Est OFF | Est ON | Both | Est OFF | Est ON | Both | |
| ASC-AS_B_DC | Control | |||||
| Est OFF | Est ON | Both | Est OFF | Est ON | Both | |
| ASC-OMC_A | Control | |||||
| Est OFF | Est ON | Both | Est OFF | Est ON | Both | |
| ASC-OMC_B | Control | |||||
| Est OFF | Est ON | Both | Est OFF | Est ON | Both | |
| OMC-DCPD_SUM_OUT | Est Off | Est ON | Both |
| OMC-REFL_A_LF_OUT | Est Off | Est ON | Both |
Jeff, Oli, this is good to know!
I also noticed that the SUSpoint L to M1 P block of the estimator does not have the corresponding filter fit. For the Pitch degree of freedom, we expect the ISI longitudinal contribution to be relevant enough that it should be modeled. Maybe this explains some of the inconsistent behavior around the length/pitch modes.
I modified 'make_SR3_pitch_model.m' inside sus/trunk/HLTS/Common/FilterDesign/Estimator to ensure that we get the correct fits into this filter bank. This update is current as of SVN revision 12616
In total, autoquack should populate 3 filter banks for the pitch estimator:
Wow. Thanks for all the data. One quick clarification. Above it says "Of course the peaks at 0.6 and 0.7 Hz are elevated in the estimator plots below due to not damping them in the inital blend filter"
To be clear, the first version of the pitch estimator was designed to damp these peaks. But - recall that "estimator" is the blend of the model and the measurements. In the first version, nearly all of the damping signal in the estimator was from the MODEL, whereas the 2 higher frequency peaks (and all 3 yaw peaks) use the MEASUREMENT path from estimator. In version 1, the model path for the estimator wasn't working well. This seems to mean that the model is not correctly predicting the gap motion. We suspect that this is because of an unmodeled drive, which we think is DAC noise.
So we were applying damping with the estimator, but it was not working as expected. Version 2 has updated blend filters which use the osem signals around all 4 peak frequencies, and hopefully this will improve the estimator performance.