Reports until 09:54, Wednesday 17 April 2019
H1 PSL (PSL)
peter.king@LIGO.ORG - posted 09:54, Wednesday 17 April 2019 - last comment - 06:28, Tuesday 23 April 2019(48568)
PMC relock counter
After commenting on the lock durations reported by the PSL weekly script the other day, this morning JeffB and I
happened to be looking at the PMC relock counter and noticed that it was slowly increasing whilst the PMC
seemingly remained locked (see image PMCRelockCounter.png).

    I don't know why this would be the case.
Images attached to this report
Comments related to this report
jason.oberling@LIGO.ORG - 12:11, Wednesday 17 April 2019 (48572)

Took a quick look at this.  According to the model, the relock counter reads the channel H1:PSL-PMC_LOCKED, which is a logical AND between the channels H1:PSL-PMC_LOCK_ON, H1:PSL-PMC_RESONANT, and the result of a Greater Than operation between the channels H1:PSL-PMC_TRIGGER_OUTPUT and H1:PSL-PMC_TRIGGER_MIN (no channel exists for the output of this operation); see 1st attachment for a picture of the relevant portion of the model.

I fired up both available channels from the AND operation, in addition to H1:PSL-PMC_RELOCK_COUNT and H1:PSL-PMC_LOCKED, in ndscope and watched the real-time data for a bit.  H1:PSL-PMC_RELOCK_COUNT was steadily increasing at a rate of approximately 1 increment every 3-10 seconds; there was no change in the other channels.  I then added H1:PSL-PMC-TRIGGER-OUTPUT to the plot to see if the relock counter increments were coinciding with a momentary drop of the trigger output causing the Greater Than operation in the model to fail; upon looking at several of the increments, at no point did the trigger output fall below the minimum trigger set point (0.005V).  Even when it got close to the min trigger, there was no corresponding increment in the relock counter.

Taking a more long-term look, I took ndscope out to approximately 30 days (see 2nd attachment), and it appears this increase in relock counts began sometime around 2019-03-20.  This continued until sometime on 2019-04-02, where the counter increments stopped.  The counter stayed relatively flat until 2019-04-12, when it began increasing again; the increments really took off sometime on 2019-04-15 and have been increasing steadily ever since.

So far I have found no reason for the counter to be increasing like this.  It may be worth looking at the code that handles the PMC relock counter, PMC_LOCKCOUNTER.c.  Investigation continues.

Filed FRS 12753 for this issue.

Images attached to this comment
peter.king@LIGO.ORG - 06:28, Tuesday 23 April 2019 (48683)
I took a quick cursory glance at the PMC_LOCKCOUNTER.c code and did not see anything obviously out of place,
although I had some questions which were subsequently answered by both Dave and Jonathan.

    Dave later looked at the combination of the front end model and the code.  From trend data it was concluded
that the code behaved properly.  The question became why was it that the trigger level fell below the minimum
trigger level?

    The trigger level is the DC output of the locking photodiode.  The minimum trigger level is, typically,
set to be a little lower than the DC level when the PMC is resonant.  Currently this is set to a level which
is close to the dark level output of the locking photodiode.  This was done to allow changing the overall
loop gain on the PMC servo electronically, via the AD603 variable gain amplifier.  The question remains why
is the output of the photodiode varying, and my guess is that the output offset voltage is varying due to
either fluctuations in temperature or scattered light level.  A number of the changes seem to coincide with
an excursion into the PSL Enclosure.  The remedy for this would be to increase the light level on the locking
photodiode and reduce the servo gain electronically.



  DaveB / Peter