PBL: we have found a problem with slopes reordering...

We close a loop with LGSW only REC: 20151209_213200 w/o disturb.

TN AO Gain Res. WF [nm rms] AO rec DIMM ["] JCL PCL Notes
20151210_170359 0, 0, 0 NA NA -1 F F
20151210_170422 0, 0, 0 NA NA -1 F F
Gains were 0.3 on all modes. Since we're closing the loop manually, w/o foreman config, the proper gain values and RECs are not displayed.

We load a disturb taken from FLAO directories, equivalent to 0.8" in double pass, 1kHz:

TN AO Gain Res. WF [nm rms] AO rec DIMM ["] JCL PCL Notes
20151210_171512 0, 0, 0 NA NA -1 F F
20151210_171529 0, 0, 0 NA NA -1 F F
GOX finds a bug in the numSubapsReadyVec that controls the number of subaps that are ready to be computed for slopes.

Another problem was due to the "isCameraRotated" setup: the dummy= False flag screws up all the BCU configuration, so we force it to True...


After this debug we go back to IM acquisition, starting from scratch.

We select CoG subaps: 20151019_233800

10 - 20151210_201057 shell crash, we move to x1 modal amplitudes -
10 - 20151210_203840 - -
10 - 20151210_211144 amp calibrated x0.5 -

HEXA 4.87 -0.03 7.8 215 -57
We try to home the swing arm, and to deploy it again, we are inside the LGSW FoV...


TN Plot
('20151210_223719','20151210_23223851') 20151210_223719_pcTransmission.jpg

Debug of slopes ordering

We acquire a serie of dark frames and we compare the slopes computed from these frames with the ones coming from BCU: we can match slopes #11 with frame #0.

-> slopes reordering was wrong, "subapPixelPointer" we were starting to compute slopes from columns close to center wile the pixels are read starting from frame edges. This was causing the central stripe in the IM display shift...

We double check for the same effect in the DX system: TNs: 20151211_003905, 20151211_004620. Analyzing slopes #31 and the ones evaluated from frame #0 we have 10^-8 residuals w/o software modifications...

We also check for this effect using old snapshots: we consider data from 20150703_232010: just blue slopes are 0s while yellow and red are 0.3-0.6 level...

We acquire new data: 20151211_023107 it is good, subtractions gives all 0s.

Probably the analysis of old snapshots was wrong, indeed we had a dummy subaperture added at the bottom of the frame and the PC slope computer handles differently this subaperture wrt the BCU. The PC slope computer adds this subaperture at the end of the subap list while the BCU indexes the subaps accordingly to their column position. Hence the comparison is wrong.

-- MarcoBonaglia - 11 Dec 2015
Topic revision: r3 - 08 Jan 2016, MarcoBonaglia
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback