We were able to:
- Implement and test the thermal correction reset within the CHECK_THERMAL_CORRECTION dedicated new state.
- Perform a rough calibration of the FmodErr tuning using the LNFS 8MHz frequency
- Draft the dedicated TUNE_LNSF_FREQ state logic in INJ_MAIN.
Full reorganization of the INJ_MAIN state machine to be finalized and overall new logic of the FmodErr to be tested on next available shift.
- finalizing the reorganization of the INJ_MAIN state machine which currently look as shown in Fig. 1
- modifying the set_LNFS_freq.py script in order to tune also the 6 and 56MHz frequencies correspondingly to the 8MHz frequency modification. The script get passed a delta_freq for the the 8MHz frequency and the calculations are as follow:
new_freq_8 = current_freq_8 + delta_freq
new_freq_6 = new_freq_8 / 8.0 * 6.0
new_freq_56 = new_freq_8 / 8.0 * 54.0
This morning, with a rough re-tuning of b4_dphi and a PR realignment I was able to arrive stably to LOCKED_PRITF (then I am getting unlocks trying to reach LOCKED_PRITF_DF, to be investigated tomorrow).
This was anyway enough for me to prove that if the frequencies tuning is made then the locking is not able to go farther than LOCKING_RECOMBINED. A check of the actual value of those frequencies must, most probably, be missing on the SSFS control somewhere.
I have thus removed the tuning of the frequencies (and I simply proceed straight to FMODERR_TUNED) but I have left all the rest of the new logic, in particular the thermal correction reset and the execution of the MC_F0_Z tuning only if the calculated frequency correction would be too large.
This seems working fine trough some unlocks (which imply the execution of the FModErr sequence) so I leave running this updated version of INJ_MAIN.
I leave the interferometer in LOCKED_PRITF state
We understood at least one problem that might have caused problems: Since the nominal frequency of LNFS differs by a few Hz from the demodulation frequency generated by the look-up tables in the demodulation boards, the phase is de-rotated with the hard-coded frequency difference. As a result of this, signals like DAQ_LNFS_56MHz_phi look flat. This phase is sent via TOLM at 10 kHz to the various photodiodes and SSFS_Ctrl processes, so that the signals can be demodulated at the correct angle even in case of small phase drifts.
The issue occurs when we change the modulation frequency: the phases of the LNFS are now no longer de-rotated with the correct frequency and will start wrapping around at +- pi, see fig 2. This is in principle not a problem, since adjusting a phase with a wrapped value still gives the correct answer. For the SSFS signal, however, the phase needs to be up-sampled to 500 kHz, so the anti-alias filter will cause a glitch every time the phase wraps around.
As a temporary solution, Alain removed the anti-alias filter of the phase in the SSFS_Ctrl process (so now the 10 kHz signals are simply repeated 50 times). As a more permanent solution, we could send both the LNSFS_*Hz_I/Q signals (which do not show any discontinuities, and can thus be safely up-sampled), and finally calculate the phase of the LO by doing a atan2 at 500 kHz.
We should also consider getting rid of the derotation step (which happens both at the level of the LNFS and the photodiodes), since the hard-coded difference frequency become arbitrary when we change the modulation frequency during every lock acquisition.
This week we have been working further on the new FModErr strategy:
- First the problem of incorrect transitions, reported in this entry should have been fixed by forbidding redirection on all states involved in the FModErr sequence. This can bee seen on the updated state transition diagram (Fig. 1) were all states involved in the FModErr can now be identified by the red border (specific of a state in which redirect is set to False).
- Two different thresholds on FModErr has been introduced: fmod_tol_z (8e-5) for MC_F0_Z tuning and fmod_tol_f (2e-5) for Frequency tuning
- A 8MHz_reference (8361036.0 Hz) and a threshold have been introduced to avoid moving away too much with the nominal frequency. In case the newly calculated frequency is max_freq_corr (50Hz) away from 8MHz_reference then the frequency is set back to the reference
Trying to engage the frequency tuning we encountered again the problem mentioned in this entry and we were unlocking while reaching LOCKED_CARM_TO_MC (See Fig. 2)
Today we have retuned the thresholds for the thermal correction reset. We also realized that a protection must be introduced against IMC unlock. The whole FModErr strategy is also being revised
