jeffrey.kissel@LIGO.ORG - posted 16:42, Tuesday 17 May 2016 - last comment - 16:52, Tuesday 17 May 2016(27255)
Charge Measurement Update; Latest Flip Continues to Bring Effective Bias Voltage to Zero -- Should Try Regular Flipping Soon
J. Kissel We've gathered our regular Tuesday measurement of the effective bias voltage as a result of charge on the end test masses. After the hiccup of settings loss a few week's ago (LHO aLOG 26793), the last three weeks of results confirm that both test masses are back on there way to zero effective bias voltage. Good! Also encouraging, is that the rate of charge accumulation seems to have become consistent between flips of requested bias. This didn't always used to be the case; see LHO aLOGs 22135 or 20387 in which we had evidence that the rate of charge was a crap shoot every time we flipped the requested bias sign. There's no obvious reason why it would be different between now and then, but it's good to see that it may be one less thing we have to worry about. However, recall, the plan -- to minimize time-dependent calibration error during observing runs: after we've brought the effective bias voltage to zero, regularly flip the requested ETM bias voltage such that it *stays* at zero and never accumulates. Today's results show that we're pretty darn close to zero with ETMY, so we should write that script that automatically flips the requested bias voltage and takes care of all the collateral damage (see LHO aLOG 26826) this week or next, and exercise it. Only after we regularly exercise flipping and confirm nothing goes suddenly bonkers, will we say we're comfortable doing it regularly during the run.
Images attached to this report
Comments related to this report
Remember, instructions to take and analyze the data live in the aLIGO Wiki. Also, of interest to charge measurers only, I've changed the NDS get data call that we use to obtain the requested ESD bias voltage from the old school "get_data2" to the latest sanctioned conn.fetch technique, as described in the NDS2 Client Manual. Further, I've added "try / catch" error handling surrounding the NDS call, such that when the nds client throws an error, it doesn't cause the whole analysis script to fail, it just sets that date's bias voltage to zero and then goes on. I would say that this will permanently improve the NDS troubles that we've had, but no one can make such guarantees. It still takes a whole bunch of time (on the order of minutes per call) to gather data that I hadn't requested during the given Matlab session, but once I'd gathered the data once, it breezed through the data collection, so that was nice. We'll see how well it works next week! P.S. This script, /ligo/svncommon/SusSVN/sus/trunk/QUAD/Common/Scripts/Long_Trend.m is very out of data with the repo version. As such, I can't commit the changes without a good bit of svn reconciliation. Not today.